try {
    funktion();
   ...
} catch (const std::invalid_argument& e) {
    std::cerr << "Falsches Argument:"  << e.what() << std::endl;
} catch (const std::range_error& e) {
    std::cerr << "Ungültiger Bereich:" << e.what() << std::endl;
} catch (...) {
    std::cerr << "Sonstiger Fehler" << std::endl;
}

Gängige Vorurteile

1. Die Behandlung von Ausnahmen ist codeintensiver (mehr Schreibarbeit)
   Falsch. Ein sinnvolles try/catch braucht ist sogar weniger Code als ein sinnvolles if/else if/elsefür alle möglichen Fehlercodes. Fehlercodes werden aber oft nicht vollständig überprüft oder gar ganz weggelassen, was der Qualität des Codes nicht gerade zuträglich ist. Exceptions dagegen zwingen zu einer durchdachten Fehlerbehandlung.
2. Exceptions machen den Code langsam
   Falsch. Wenn Exceptions richtig eingesetzt werden, sollten sie für Ausnahmen im Programmablauf verwendet werden. Die Ausführungsgeschwindigkeit des “Gut”-Pfades (in dem keine Ausnahmen geworfen werden) leidet nicht darunter. Wenn also die Exception die Ausnahme und nicht die Regel ist, hat man nichts zu befürchten.
3. Das Resourcen-Handling ist bei Excptions aufwändiger
   Falsch. Wenn RAII (Resource Acquisition Is Initialization) korrekt verwendet wird, muss man sich sogar weniger Sorgen um Aufräumarbeiten machen, als unter Java und C# – der Destruktor räumt die Objekte ohne Weiteres Zutun brav auf.
4. Exception blähen das Binary auf
   Leider wahr. Nichts ist umsonst. Der Ausführungscode ist tatsächlich etwas größer. Dies sollte in heutiger Zeit aber kein ausschlaggebendes Argument mehr sein – selbst für Embedded-Programmierung.

Vorteile von Exceptions

• Fehler können genau da behandelt werden, wo es Sinn macht
• Exceptions müssen behandelt werden
• Mehrdeutigkeiten werden vermieden (RetCode=3 mag in einem Fall OK, in anderem ein bestimmter Fehler sein)
• Es können Fehler-Objekte anstatt simplen Zahlen verwendet werden

Caveat Exception Safety

Das Behandeln von Ausnahmen beim Erstellen von Objekten, also im Konstruktor, ist mit Vorsicht zu genießen, da in diesem Fall das Objekt noch nicht vollständig erzeugtist und der Destruktor es daher auch nicht aufräumen

kann. Es entstehen Memory-Leaks. Das Werfen von Ausnahmen im Konstruktor ist daher generell keine gute Idee.
Die Objekterzeugung Exception Safe zu machen, ist nicht ganz trivial, vor allem dann nicht, wenn sie erhalten bleiben soll, wenn die Klasse irgendwann erweitert wird. Daher kann eine einfache Möglichkeit sein, alles im Konstruktor zu unterlassen, was zu einer Ausnahme führen kann, die nicht abgefangen werden kann.
Im Allgemeinen wird zwischen verschiedenen Stufen von Exception Safety unterschieden (siehe Wikipedia):

• No exception safety
• Minimal exception safety (no-leak guarantee)
• Basic exception safety
• Commit or rollback semantics (strong exception safety/no-change guarantee)
• Failure transparency (throw guarantee)

Gründe gegen Exceptions

• Konsistenz: Es macht wenig Sinn, wenn eine bestimmte Methode einer Bibliothek Ausnahmen wirft, wenn dies im Rest der Bibliothek nicht der Fall ist. Dies würde die Verwendbarkeit einschränken. Qt verwendet aus diesem historischen Grund z.B. nur in neueren Bibliotheken Exceptions.
• Unwissenheit: Wer sich mit der Behandlung von Ausnahmen nicht auskennt, sollte lieber erst mit Beispielen üben, bevor Exceptions an vorderster Front eingesetzt werden.

Fazit

Insgesamt führt Exceptions im Allgemeinen zu einer besseren Codequalität, da man das Fehlerhandling gezielter und duchdachter gestaltet. Aus heutiger Sicht gibt es meiner Meinung nach kaum haltbare Argumente, Exceptions nicht zu verwenden.

Quellen

• C++ Coding Standards, Herb Sutter und Andrei Alexandrescu
• http://www.parashift.com/c++-faq-lite/exceptions.html

• Stativ Bilora Twister Pro
• Stativ Cullmann Magnesit 525
• Kopf Cullmann Magnesit MB4.3 bzw. MB4.1+SK-Einheit MX445 (einzeln wars günstiger)
• Kopf Vanguard SBH-100

Ich habe mich mit folgenem Text an den Metz-Kundendiesnt gewandt (und prompt auch Antwort erhalten):

Hallo,
leider bekomme ich bei Serienaufnahmen mit meiner Nikon D90 und dem Mecablitz 50 AF-1 immer wieder dunkle Bilder in der Serie. D.h. von 4 Bildern ist oftmals eines ohne Blitz.
Woran könnte dies liegen? Sieht für mich nach einem Timing-Problem aus, so dass es dann in einigen Fällen der Serie nicht klappt.
Die Firmware ist bei beiden Geräten auf dem aktuellsten Stand. Als Objektiv wurde stets das 18-105er Standard verwendet (Typ E).
Dieses Problem habe ich leider auch schon in diversen Foren und in Amazon-Bewertungen gefunden.
Vielleicht können Sie mir da weiterhelfen. Gerne helfe ich Ihnen beim Reproduzieren des Fehlers.

Kurz drauf bekam ich diese ausfühliche Antwot vom Metz:

Sehr geehrter Herr Mücke,

Ihre E-Mail-Anfrage haben wir dankend erhalten.

Grundsätzlich ist bei Serienaufnahmen mit Blitzlicht zu beachten, dass diese im Regelfall nur im manuellen Blitzbetrieb mit manuellen Teillichtleistungsstufen durchgeführt werden können. Nur mit entsprechenden Teillichtleistungsstufen kann auch eine feste Blitzfolgezeit eingehalten werden. Dies ist notwendig damit das Blitzgerät bei jeder Kameraauslösung auch blitzbereit ist. Zudem werden im manuellen Teillichtleistungsbetrieb auch keine Vorblitze vom Blitzgerät abgegeben.

Wird dagegen ein Blitzgerät, wie z. B. der mecablitz 50 AF-1 digital für Nikon, in Verbindung mit der Digital-Kamera Nikon D90 im i-TTL-Blitzbetrieb eingesetzt, so muss das Blitzgerät in diesem Fall einen oder zwei Vorblitze abgeben. Aufgrund dieser Vorblitze ermittelt dann die Kamera die notwendige Blitzlichtmenge für die spätere Aufnahme. In dieser Betriebsart kann es daher vorkommen, dass das Blitzgerät nach Abgabe einer größeren Lichtmenge nicht mehr blitzbereit ist bzw. nicht sofort wieder blitzbereit ist.

Wird nun die Kamera aufgrund der Serienaufnahmefunktion sofort wieder ausgelöst, so wird das Blitzgerät nicht mitblitzen und die Aufnahme ist dunkel. Aus diesem Grund ist die Verwendung des i-TTL-Blitzbetriebes in Verbindung mit Serienaufnahmen nicht in jedem Fall empfehlenswert.

Mit freundlichen Grüßen

i.A. XXXXX
Kundendienst Technik/Sachbearbeiter

Da sag ich nur Hut ab! vor so einem Support!

Hier geht’s zu den Bildern…

Ein Beispiel für ein solches Problem ist das Problem des Handlungsreisenden (Traveling Salesman Problem), bei dem es darum geht, eine bestimmte Anzahl von Städten so zu besuchen, dass ein möglichst kurzer Weg zurückgelegt wird, jedoch keine Stadt mehrmals besucht wird.

Weiterführende Links:

• P ≠ NP (Greg and Kat’s blog)
• de.wikipedia.org/wiki/P-NP-Problem
• en.wikipedia.org/wiki/P_versus_NP_problem
• de.wikipedia.org/wiki/Problem_des_Handlungsreisenden

Es war waren nur Zitronenscheiben und Orangenscheiben und jede Menge Eiswürfel und Zucker darin. Einfach wahnsinnig erfrischend.

Ein Rezept das diesem nahe kommt ist hier zu finden: Alles über Sangria

Oder man macht es wie folgt (Catalanische Variante):

Zutaten für vier Personen:

• 1 Flasche spanischer Rotwein (vorzugsweise RIOJA, kann aber auch ein günstigerer sein)
• Saft von mindestens zwei Orangen (ca. 100ml)
• 100ml weißer Rum
• 1 unbehandelte Zitrone
• 1 unbehandelte Orange
• 5 Eßlöffel Zucker
• 1 Zimtstange
• Eiswürfel

Zubereitung:

1. Zitrone und Orange unter heißem Wasser abwaschen und dann in (halbe) Scheiben schneiden.
2. Obststücke, Zucker, Rum und Orangensaft in eine Karaffe oder große Schüssel geben und dann ab damit zum Durchziehen in den Kühlschrank (mind. 1 Stunde).
3. Dann den Rotwein drüber, die Zimtstange hinein und das ganze umrühren. Die Sangría eine weitere Stunde kalt stellen.
4. Jetzt kommen noch ordentlich Eiswürfel dazu und die Sangría ist fertig zum servieren (am besten in großen Gläsern).

• -jX um das Erstellen mit X Prozessen parallel zu starten
• --build-type=complete baut alle libs (static, shared, mutithreaded,…)
• --with-serialization baut nur die serialization Bibliotheken

Serialization weigert sich in 1.36.0 allerdings (in 1.40 gibt’s dieses Problem nicht mehr). Hierzu ist in der libs/serialization/build/Jamfile.v2 folgende Ersetzung vorzunehmen:

: requirements ../../config/test/all//BOOST_NO_STD_LOCALE

in

: requirements

sowie
../../config/test/all//BOOST_NO_STD_WSTREAMBUF am Ende der Datei auskommentieren (‘#’).

bjam gibt’s hier: http://www.boost.org/users/download/

Danach sollten ein paar libs in stage64/lib liegen.

Mit folgendem Code gings dann ganz leicht. Einziger Nachteil: es wird immer ein zusätzlicher <value>-Tag eingefügt.

// \file qstring_serialization.h
//  Enables serialization of Qt QString
//
//  Copyright (c) 2010 Florian Muecke. Distributed under the Boost
//  Software License, Version 1.0. (See accompanying file
//  LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
 
#ifndef QSTRING_SERIALIZATION_H
#define QSTRING_SERIALIZATION_H
 
#include <QString>
#include <string>
#include <boost/archive/xml_iarchive.hpp>
#include <boost/archive/xml_oarchive.hpp>
#include <boost/serialization/string.hpp>
 
namespace boost {
namespace serialization {
 
 
template<class Archive>
inline void save( Archive& ar, const QString& s, const unsigned int /*version*/ )
{
	using boost::serialization::make_nvp;
	ar << make_nvp("value", s.toStdString());
}
 
template<class Archive>
inline void load( Archive& ar, QString& s, const unsigned int /*version*/ )
{
	using boost::serialization::make_nvp;
 
	std::string stdStr;
	ar >> make_nvp("value", stdStr);
	s = QString::fromStdString(stdStr);
}
 
template<class Archive>
inline void serialize( Archive& ar, QString& s, const unsigned int file_version )
{
	boost::serialization::split_free(ar, s, file_version);
}
 
} // namespace serialization
} // namespace boost
 
#endif // QSTRING_SERIALIZATION_H

Analog kann man das Ganze natürlich auch für CString in der MFC machen…

Die Meldung besagte weiterhin, man solle den Drucker aus und dann wieder einschalten. Und falls das nichts bringen sollte, solle man das Handbuch zu Rate ziehen. Und wenn das nichts hilft natürlich den Drucker einschicken.

Das dies nichts gebracht hat muss ich an dieser Stelle wohl nicht näher ausführen. Google sei dank habe ich aber dann doch noch eine Lösung gefunden. Anscheinend hat sich was beim Papiereinzug verklemmt.

Reperaturanweisung

• Wenn der Fehler auftritt lässt sich der Druckkopf frei auf den Stangen bewegen.
• Wichtig: Netzstecker raus!
• Vordere obere und CD-Druckklappe öffnen.
• Druckkopf ganz nach links schieben.
• Rechts in den Drucker schauen und dort ein weißes Plastikteil mit den ca. 3mm hohen Kunstoffnippel ganz nach unten drücken bis es klickt.
• Druckkopf wieder nach rechts schieben und Druckerklappen schließen.
• Gerät wieder anschließen und einschalten.

Nach dem Einschalten und vor dem ersten Druckvorgang hat der Drucker sich dann lediglich eine Weile gereinigt und irgendwie neu positioniert. Danach ging er wieder einwandfrei.