Es gibt aber auch andere Situationen, in denen dir vielleicht völlig egal ist, ob eine Operation erfolgreich war oder nicht und du daher nicht mit Exceptions belästigt werden willst. Oder Situationen, in denen du lieber einen Defaultwert statt einer Exception haben möchtest (z.B. bei lexical_cast, wenn du gerade nicht Datenstrukturen aus einem Stream liest).

Wenn z.B. ein std::fstream eine Datei nicht öffnen kann, wird keine Exception geworfen, sondern ein objektinterner Wert verändert.

Wenn du Bitte sagst wirft dir der Stream auch eine Exception:
http://www.cplusplus.com/reference/iostream/ios/exceptions/

Hallo,
wann ist es sinnvoll Exceptions zu nutzen und wann sollte man Fehler durch "normalen" Code abfangen.

Wenn etwas einen "Fehler" darstellt, dann solltest du eine Exception werfen.
Wenn etwas "erwarteterweise" passieren kann, dann solltest du keine Exception werfen.

Die beiden Bedingungen schliessen sich jetzt gegenseitig natürlich nicht aus.
Das heisst aber nicht dass man in Fällen wo beides zutrifft einfach würfeln sollte, sondern dass man in den Fällen dann beide Möglichkeiten anbieten sollte.

Oft liest man dass man statt dessen lieber eine Möglichkeit anbieten sollte vorher abzuchecken ob das was man tun möchte auch möglich ist. z.B. vorher gucken ob das File überhaupt da ist, und dann erst versuchen es aufzumachen.
mMn. ist das aber Quatsch. Erstens sind verdammt viele Dinge "transient" - ob ein File da ist oder nicht kann sich jederzeit ändern. Dann gibt es Dinge wo ein Vorabcheck einfach unnötig Rechenzeit verbrät. Und dann gibt es Fälle wo ein Vorabcheck kompliziert ist, oder Wissen über bestimmte Implementierungsdetails voraussetzt.

Also statt

if (can_i_do_it())
   do_it();
else
   scheissendreck();

lieber

if (!try_do_it())
   scheissendreck();

Und wie gesagt: wenn beides Sinn macht ("do_it" und "try_do_it"), auch beides anbieten.