Alternativen zu Exceptions?
-
Es gibt vieles. Aber Exception haben sich durchgesetzt (und das aus gutem Grund)
http://www.vollmann.ch/en/pubs/cpp-excpt-alt.html
http://gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.htmlspeziell:
Error Stack, Deferred Error Handling, Callbacks und Conditions.
-
verwüstung schrieb:
ShadowClone schrieb:
Optional
Ich weiß, dass du ein Troll bist aber ich beiße dennoch mal zu:
Inwiefern ist Optional ein Konzept zur Propagation von fehlerhaften Zuständen?Was ist denn das für eine Polemik?! Es gibt Exception-freie Sprachen. Funktionale Sprachen kennen keine Exceptions. Rust ebenfalls nicht:
-
ShadowClone schrieb:
Rust ebenfalls nicht:
https://doc.rust-lang.org/book/error-handling.htmlMit Grund, wieso Rust solcher Mist ist. Wenn ich wie anno 1960 Rückgabewerte auf Fehler prüfen will, dann nutze ich C.
Außerdem: Muss ich daraus schließen, dass ich in Rust entweder Laufzeitoverhead habe, weil der Rückgabewert dynamisch entweder der echte Rückgabewert oder die Exception sein kann, oder auf Reproduzierbarkeit und andere hilfreiche Einsicht bzgl. des Fehlers verzichten muss?
-
verwüstung schrieb:
ShadowClone schrieb:
Rust ebenfalls nicht:
https://doc.rust-lang.org/book/error-handling.htmlMit Grund, wieso Rust solcher Mist ist. Wenn ich wie anno 1960 Rückgabewerte auf Fehler prüfen will, dann nutze ich C.
Außerdem: Muss ich daraus schließen, dass ich in Rust entweder Laufzeitoverhead habe, weil der Rückgabewert dynamisch entweder der echte Rückgabewert oder die Exception sein kann, oder auf Reproduzierbarkeit und andere hilfreiche Einsicht bzgl. des Fehlers verzichten muss?Zuerst mich dumm anmachen und so tun als könnte ich mit Optionals keine Fehler propagieren und wenn ich dann das Gegenteil beweise, dies als Mist darstellen und mit C vergleichen und dann auch noch andeuten, dass das mit Overhead verbunden ist.
Von der Polemik und vom Eindruck her, musst du der Kenner der Idioten sein. --> Mit dir diskutiere ich nicht weiter. Wenn du noch nie ernsthaft über den Tellerrand geschaut hast und nicht mal die Grundlagen einer anständigen Kommunikation kennst, dann ist das nur verschwendete Zeit!@Mods: Ernsthaft: Ihr müsst endlich mal die Registrierungspflicht einführen!
-
Vielen Dank für die Antworten, insbesondere an Shade of Mine.
Optional ist für mich ganz klar Fehlerpropagierung über den Returnwert.
-
Ethon schrieb:
Gibt es eigentlich Konzepte, die als Alternative zu Exceptions gesehen werden können?
Die meisten wurden ja genannt. Falls dich eine weiterführende Diskussion der Problematik interessiert, kann ich diesen Artikel empfehlen; das ist das beste, was ich in letzter Zeit dazu gelesen habe.
http://joeduffyblog.com/2016/02/07/the-error-model/
Die zugrundeliegende Frage ist: wenn man OS, Programmiersprache und Laufzeitumgebung von Grund auf neu entwerfen und aufeinander abstimmen könnte und dabei den größten Wert auf Zuverlässigkeit legte: welches Fehlermodell sollte man dann verwenden? Die Ergebnisse lassen sich deshalb nur bedingt auf andere Sprachen übertragen. Jedenfalls läuft es darauf hinaus, eine Unterscheidung zwischen bugs und recoverable errors einzuführen; erstere führen zur Termination des Prozesses, der Rest wird durch richtige checked exceptions (also ohne
RuntimeException-Ausnahmen) abgebildet. Damit das ganze System benutzbar bleibt, müssen dafür allerdings Prozesse viel granularer werden, so daß das Scheitern eines einzelnen Prozesses viel überschaubarere Auswirkungen hat.
-
audacia schrieb:
checked exceptions (also ohne
RuntimeException-Ausnahmen)Bitte nicht.
http://www.artima.com/intv/handcuffs.htmlChecked Exceptions werden gemeinhin als schlecht angesehen - was man daran merkt dass keine andere moderne Sprache hier Java gefolgt ist.
-
Shade Of Mine schrieb:
audacia schrieb:
checked exceptions (also ohne
RuntimeException-Ausnahmen)Bitte nicht.
http://www.artima.com/intv/handcuffs.htmlChecked Exceptions werden gemeinhin als schlecht angesehen - was man daran merkt dass keine andere moderne Sprache hier Java gefolgt ist.
Das eine ist Systemtheorie, das andere Praxis
-
Shade Of Mine schrieb:
Bitte nicht.
http://www.artima.com/intv/handcuffs.htmlBitte erst den Artikel lesen. Der nimmt ausdrücklich Bezug auf dieses Interview mit Anders Hejlsberg.
-
C++(und andere Sprachen) Exception "Probleme"
http://www.shanekirk.com/2015/06/c-exceptions-the-good-the-bad-and-the-ugly/
ScopeGuards in C++ - ein andere Varianten von Fehler/Transaktions-Sicherung
https://www.youtube.com/watch?v=WjTrfoiB0MQ
-
D hat ScopeGuards eingebaut:
-
schönen Beispiel für die D ScopeGuards - und warum der Code lesbarer bleibt
-
-
Gast3 schrieb:
schönen Beispiel für die D ScopeGuards - und warum der Code lesbarer bleibt
https://dlang.org/exception-safe.htmlIch finde, bei dem Vergleich RAII versus ScopeGuards kommt es drauf an, wie oft der Kram benutzt wird. So eine Klasse im RAII-Fall wie z.B.
std::lock_guardwird nur einmal definiert und an potentiell vielen Stellen benutzt. Dann lohnt sich dessen Existenz. Wenn man die RAII-Klasse nur an einer einzigen Stelle benutzen würde, ja dann hätte ich wahrscheinlich auch keine Lust, sie zu schreiben.verwüstung schrieb:
ShadowClone schrieb:
Rust ebenfalls nicht:
https://doc.rust-lang.org/book/error-handling.htmlMit Grund, wieso Rust solcher Mist ist. Wenn ich wie anno 1960 Rückgabewerte auf Fehler prüfen will, dann nutze ich C.
Du warst anscheinend zu faul, das Error Handling Kapitel bis einschließlich des Abschnitts "The
try!macro" zu lesen. Ich nehm's Dir nicht übel. Es sind ja insgesamt ca 40 Seiten.Das manuelle Prüfen von Rückgabewerten in C ist nervig und fehleranfällig. Man will nicht überall testen, ob das, was man machen wollte, geklappt hat. Und man will auch nicht Fehler versehentlich "verschlucken" (ignorieren).
Die
Result<T,E>Typfamilie zusammen mit demtry!Makro und den Konvertierungs-Traits (From,Into) erfordert kein manuelles Prüfen auf Fehlern. Es ist in Rust auch viel schwieriger, Fehler versehentlich zu ignorieren. Man muss so einResult<T,E>irgendwie konsumieren, sonst warnt einen der Compiler. Das Konsumieren eines solchen Wertes geht auf mehreren Arten und Weisen: (1) Matching, (2) Combinators, (3) Das try! Makro. Unter der Haube läuft das alles auf Matching hinaus. Option 2 und 3 sind aber syntaktisch süß. Das mit dem try! Makro fühlt sich eher wie Ausnahmen in anderen Sprachen an.
-
Wenn man die RAII-Klasse nur an einer einzigen Stelle benutzen würde, ja dann hätte ich wahrscheinlich auch keine Lust, sie zu schreiben.
Genau das ist das Problem mit try/catch und RAII - alle sagen das muss man so machen weil es richtig toll und gut ist - aber keiner macht es ordentlich oder konsequent
Fehler versehentlich zu ignorieren. Man muss so ein Result<T,E> irgendwie konsumieren
aber ich kann einen Nicht-Fehler einfache unwrappen - klar das ist kein Undefined Behavior aber eine winzige Lücke die sich für mich nach nicht-vollständig-geschlossen anfühlt - egal wie unwahrscheinlich die Falsch-Nutzung ist, vergleichbar mit 2 unique_ptr mit 1 echten ptr belegen - total idiotisch, geht aber - sowas ist z.B. in safe Rust nicht möglich, und das die Results als Sum-Types immer die Größe des größten Typs annehmen - ok das ist pure Value-Semantik - aber mir schmeckt das noch nicht so ganz
-
...aber keiner macht es ordentlich oder konsequent
der der Rest ruft laut nach "finally" um das "Problem" zu lösen
-
audacia schrieb:
Ethon schrieb:
Gibt es eigentlich Konzepte, die als Alternative zu Exceptions gesehen werden können?
Die meisten wurden ja genannt. Falls dich eine weiterführende Diskussion der Problematik interessiert, kann ich diesen Artikel empfehlen; das ist das beste, was ich in letzter Zeit dazu gelesen habe.
http://joeduffyblog.com/2016/02/07/the-error-model/
Die zugrundeliegende Frage ist: wenn man OS, Programmiersprache und Laufzeitumgebung von Grund auf neu entwerfen und aufeinander abstimmen könnte und dabei den größten Wert auf Zuverlässigkeit legte: welches Fehlermodell sollte man dann verwenden? Die Ergebnisse lassen sich deshalb nur bedingt auf andere Sprachen übertragen. Jedenfalls läuft es darauf hinaus, eine Unterscheidung zwischen bugs und recoverable errors einzuführen; erstere führen zur Termination des Prozesses, der Rest wird durch richtige checked exceptions (also ohne
RuntimeException-Ausnahmen) abgebildet. Damit das ganze System benutzbar bleibt, müssen dafür allerdings Prozesse viel granularer werden, so daß das Scheitern eines einzelnen Prozesses viel überschaubarere Auswirkungen hat.Lesenswerter Artikel. Wir compilieren mit Hilfe von https://github.com/Fody/Fody NullChecks in unsere Libraries und haben in C# non-null-by-default-behavior für Methodenparameter umgesetzt. Fühlt sich sehr fein an. Aber hätte es sehr sehr gerne gesehen non-null-by-default in C# 7 zu sehen, schade, dass es nichts geworden ist
MfG SideWinder
