Kann ich schwer sagen. Ich war mal sehr prozedural und kannte daher gar keine Exceptions (die sind doch OOP-only, oder?). Inzwischen benutze ich hauptsächlich Java (Studium) und bin daher zumindest mit den von Java selbst geworfenen Exceptions konfrontiert, die ich meistens aber gar nicht fange, weil ich auch nur irgendwelche Methoden implementiere, die dann mit falschem Input gefüttert wurden und die Exception daher ruhig den Caller erreichen soll - ich könnte sie höchstens noch in eine eigene Exception wrappen, aber was bringt das?Zitat von Kyuu
Ich finde das Konzept von Exceptions eigentlich sehr sinnvoll, auch wenn ich sie wenig nutze. Insbesondere bei Rekursion können sie Fehlerbehandlung sehr vereinfachen und in ihnen lassen sich gleich detailliertere Informationen über die Art des Fehlers speichern - die "C-Approach", nur nen Fehlercode zurückzuliefern unter dem sich der Programmierer/der Benutzer dann was vorstellen soll, finde ich da ziemlich braindead. In ner Exception kann ich dann auch gleich schreiben, welche Datei nicht geöffnet werden konnte, in welcher Rekursionstiefe das Problem aufgetreten ist, und diese Informationen an der relevanten Stelle wieder auswerten, ohne sie erstmal dahin transportieren zu müssen.
Sind Assertions nicht auch nur Exceptions, die unter bestimmten Umständen fliegen?
Ich würde sagen, intern auch für trivialere Dinge verwenden, wenns die einfachste Implementierung ist, nach außen nur kommen lassen, wenn der Aufrufende Schuld ist. Wenns ein UI gibt, und der User Schuld ist, natürlich schon fangen, aber dem User präsentieren und so...
Anyway, netter Artikel...
Zitieren