Exception Handling (Eure Konzepte, best practice,..)
-
Roger Wilco schrieb:
Aber grundsätzlich fängt man nicht alle std::esceptions und wirft was eigenes, nur um eine einheitliche oder std-freie Schnittstelle bezüglich Exceptions zu besitzen, oder?
Grundsätzlich nicht, nein. Wenn es sinn macht kann man das tun, aber nicht um eine std::xyz_exception in eine mynamespace::XYZException umzuwandeln sondern eher um z.B. bei der wüsten Kalkulation mit zig 3D-Vectoren irgendeines frameworks, std::containerzugriffen und diversen anderem Kram alles einzusammeln und eine allgemeine CouldNotCalculateMyGrandmasAnnuityException zu werfen. Ich machs im Grunde sogar so, dass ich meine Exceptions von std::exceptions ableite, ein sinnvolles what() beisteure udn so dafür sorge dass im Zweifel an den Grenzen meines Zuständigkeitsbereichs alles mit einem "catch(std::exception& e)" gefangen werden kann.
Damit gehören dann z.B. std::bad_alloc oder std::lenght_error mit zur Schnittstelle der eigenen Klassen.
Jein. Sie können zwar aus der benutzung deiner Klassen heraus fliegen, gehören aber nicht eigentlich zur Schnittstelle. Das Excepion-System ist ein recht eigenes System im Vergleich zu den "normalen" Klassenhierarchien.
-
Shade Of Mine schrieb:
was das loggen betrifft: du kannst uU uncaught_exception() in einem dtor verwenden um exceptions zu loggen. stackguards können für sowas ganz gut verwendet werden.
Da man im Prinzip beliebig grosse Programmteile während des Stack-Unwindings laufen lassen kann, ist std::uncaught_exception() eigentlich total witzlos.
Stell dir vor du lässt in einem dtor irgendwelchen Cleanup-Code laufen.
Der Cleanup-Code läuft dann mit std::uncaught_exception() == true, obwohl im Cleanup-Code selbst garkeine Exceptions geworfen werden. Der Cleanup-Code würde dann die ganze Zeit irgendwelchen Schwachsinn loggen, weil er glaubt dass ne Exception von etwas geworfen wurde was er selbst machen wollte. Was aber garnicht stimmt.Faustregel: std::uncaught_exception() kann man vergessen, weil es immer Fälle gibt, in denen es nicht das tut zurückliefert was man sich erwarten würde.
-
pumuckl schrieb:
...um z.B. bei der wüsten Kalkulation mit zig 3D-Vectoren irgendeines frameworks, std::containerzugriffen und diversen anderem Kram alles einzusammeln und eine allgemeine CouldNotCalculateMyGrandmasAnnuityException zu werfen. Ich machs im Grunde sogar so, dass ich meine Exceptions von std::exceptions ableite, ein sinnvolles what() beisteure udn so dafür sorge dass im Zweifel an den Grenzen meines Zuständigkeitsbereichs alles mit einem "catch(std::exception& e)" gefangen werden kann.
Das war nun auch meine Vorstellung. Nur frage ich mich, wann soll ich das machen. Das "Einsammeln" und werfen einer zusammenfassenden Exception. Man könnte es ja theoretisch bei jeder Methode (die fehlschlagen könnte) machen. Das wäre schön einheitlich, erhöht aber die Anzahl Exception-Klassen. Oder man wägt ab, bei welcher Menge an "Low-Level"-Exceptions man das macht.
Jein. Sie können zwar aus der benutzung deiner Klassen heraus fliegen, gehören aber nicht eigentlich zur Schnittstelle. Das Excepion-System ist ein recht eigenes System im Vergleich zu den "normalen" Klassenhierarchien.
Aber ein Kunde Deiner Klasse weiß ja im Grunde nichts über Deine Implementierung. Dann muss er auch wissen, was da so alles geflogen kommen kann. Das gehört für mich dann schon zur Schnittstelle.
-
Roger Wilco schrieb:
Aber ein Kunde Deiner Klasse weiß ja im Grunde nichts über Deine Implementierung. Dann muss er auch wissen, was da so alles geflogen kommen kann. Das gehört für mich dann schon zur Schnittstelle.
Deshalb ja auch "jein". Grundsätzlich kann ein Client damit rechnen, dass ein std::bad_alloc aus so ziemlich jeder Funktion geflogen kommen kann die kein Destruktor ist und nicht swap heißt (die beiden sollten NIE Exceptions werfen bzw. zulassen). Andere Fehler die wirklich nicht behandelbar sind (z.B. Framework xy hat sich komplett verabschiedet und ist nicht mehr zu retten, das Programm liegt in Trümmern...) können auch undokumentiert durchrauschen. Alles weitere kommt entweder aus meinem Bereich oder kam aus einem tiefer liegenden Bereich und wird in dem Fall von mir an den Grenzen übersetzt.
