Diskussion:Ausnahmebehandlung

Titel

Bitte wer sagt "Ausnahmebehandlung"? Genau, keine Sau! Das heißt "exception handling", auch in Deutsch, da können die Germanophilen und Anglophoben jammern was sie wollen. (nicht signierter Beitrag von 195.72.132.1 (Diskussion) 14:15, 24. Jan. 2012 (CET))

Technische Umsetzung

Im Artikel steht:

In JIT-compilierten Sprachen wie z.B. Java und C# kann auf den Overhead des ständigen Protokollierens verzichtet werden, da der Quellcode bei Auftreten einer Ausnahme nach einem passenden Handler abgesucht werden kann

Ich kann mir das ehrlichgesagt beim besten Willen nicht vorstellen, dass das so sein soll - zumal der Quellcode bei Java/C#-Programmen oftmals gar nicht mitgeliefert ist. Was evtl. möglich sein könnte, wäre den Bytecode durchzugehen, aber auch das scheint mir recht unwahrscheinlich (aus diversen Gründen). Kann jemand den Abschnitt bestätigen oder - wenn nicht - ihn entfernen? --Mark Nowiasz 21:00, 14. Dez 2005 (CET)

Ich habe nun mal den merkwürdigen Abschnitt entfernt... --Mark Nowiasz 20:47, 21. Jan 2006 (CET)

Ich habe den Abschnitt mal wieder eingefügt und "Quellcode" durch "Bytecode" ersetzt. Du lagst mit Deiner Vermutung schon ganz richtig: der Bytecode enthält (zumindest bei Java) für jede Methode ein "Code"-Attribut, das eine Tabelle mit Exception-Handlern enthält. --Monochromata 20:48, 23. Jan 2006 (CET)

In nativ compilierten Sprachen wie C++ wird meistens Code generiert, der zur Laufzeit Informationen zur Ausnahmebehandlung protokolliert.

das ist nicht richtig. moderne compiler verwenden exception tables, in denen anhand der aktuellen instruction (wo die exception aufgetreten ist) der richtige stack frame zur behandlung gefunden wird. kein runtime-overhead. im grunde wie bei VMs, nur dass die benötigten informationen als tabelle vorbereitet werden anstatt sie im exception-fall aus dem bytecode rauszusuchen. (nicht signierter Beitrag von 85.214.83.222 (Diskussion | Beiträge) 21:46, 13. Sep. 2009 (CEST))

Geschichte ? Wer war der Erste ?

Exception-Handling hat sich ja mittlwerweile etabliert. Ich frage mich nur, wer hats sich ausgedacht, wer zuerste implementiert ? --Peritus 11:36, 12. Dez. 2006 (CET)

Exceptions gab es schon in PL/I, vlt. sollte man dort bei einer Recherche ansetzen.

Delphi-Beispiel fehlerhaft

Mir ist keine Möglichkeit bekannt, einen try-except-finally-Block zu erstellen. Eventuell meinte der Autor folgendes:

 try
   try
     ErstelleObjektA;
     BerechneEinkommen(name);
   except
     on E:Exception do
     begin
       // Exception wurde abgefangen und wird um einen aussagekräftigen Hinweis ergänzt
       E.Message := 'Fehler beim Berechnen des Einkommens von ' + name + #13#10 + E.Message;
       Raise;  // veränderte Exception erneut auslösen
     end;
   end;
 finally
   EntferneObjektA; //dies wird auf jeden Fall ausgeführt
 end;

-- F. Gärtner, 10:35, 29. Dez. 2006 (CET)

Abkürzung SEH

Beim SEH abgekürzten Süddeutschen Eisenbahnmuseum hat eine IP das Wort Structured Exception Handler aufgebracht, den es in der WP nicht gibt, aber Google findet außerhalb einen server http://www.rohitab.com/sourcecode/seh.html dazu. Bringt der was? - was hier relevant wäre? Ich meinte nicht --SonniWP✉✍ 11:59, 12. Okt. 2007 (CEST)

Ganz konkret gefragt: Sollte man den redirect SEH in eine Begriffsklärung umwandeln und den Begriff Structured Exeption Handler mit hineinnehmen ? --Sam Gamtschie 23:34, 12. Okt. 2007 (CEST)

Checked Exceptions

Ich habe den Abschnitt zu Checked Exceptions weitgehend neu geschrieben. Gründe:

Java hat hinsichtlich der Ausnahmebehandlung eine besondere Finesse:

Naja, das ist nicht wirklich objektiv formuliert

Daher ist es in Java kaum noch möglich, dass eine Exception ein Programm unerwartet zum Absturz bringt.

Natürlich ist es möglich, dass Errors und RuntimeExceptions dies tun, man bedenke, dass kein Compiler Programmierer daran hindert, eigene Exception-Klassen als Checked Exception zu implementieren.

Ausgenommen hiervon sind Ausnahmetypen, die jederzeit auftreten können, wie zum Beispiel Indexfehler bei Array-Indizierung.

„Jederzeit auftreten können“ stimmt nun auch nicht, das hängt von der Qualität des Codes ab. Das Entscheidende ist, hat der Aufrufer Einfluss darauf.

Man könne das Verhalten (bzgl. der geworfenen Ausnahmen) einer Methode nicht mehr einfach ändern, da man damit die Signatur, also die Schnittstelle der Methode verändere. Client-Code, der diese Methode dann nutze, würde sich nicht mehr kompilieren lassen.

Hier sind Indikative statt Konjunktive angebracht – das sind Fakten – aber deshalb nicht unbedingt Nachteile.

Demgegenüber argumentieren Verfechter dieses Systems, dass das Brechen mit Client-Code ohne „checked“ Exceptions genauso stattfinden würde. Anstatt eines Compilerfehlers würde dann eine ungefangene Ausnahme das bisher abgesicherte Programm gefährden und das möglicherweise sogar unbemerkt.

Das sind auch Fakten – die eigentliche Pro-Contra-Argumentation müsste darüber stattfinden, ob das akzeptabel ist oder nicht. Gibt es Quellen für diese Argumentation? --Leo141 23:27, 9. Okt. 2008 (CEST)

Du hast vollkommen Recht und deine Formulierung ist wesentlich besser. :-) Darfst du nächstes Mal auch selber sichten. ;-) --j ?! 16:39, 10. Okt. 2008 (CEST)

@Leo141, Jpp, Ch0peng: Sollte das Kapitel "Checked Exceptions" nicht besser in der Artikel Java verschoben werden, da es eine Eigenheit von Java ist? --Trustable (Diskussion) 09:21, 15. Mär. 2017 (CET)

Checked Exceptions sind bzw. wurden, heute ist man sich weitgehend einig, lange im Bereich der angewandten Informatik und allgm. Sprachdesign diskutiert z.B. gab es auch in C++ Diskussionen oder C# (Interview mit Anders Hejlsberg ein leitender Architekt von C#) -> sollte also hier bleiben. Java ist jedoch die einzige Sprache mit nennenswerter Reichweite, die das Konzept umgesetzt hat -> sollte im Java Artikel erwähnung finden siehe meinen Kommentar auf der dortigen Disk. --Ch0peng (Diskussion) 11:32, 15. Mär. 2017 (CET)

Beispiel in c++

Es mag ja nur ein Schönheitsfehler sein, aber man sollte in c++ immer const class& fangen und nicht class&, im Beispiel also

     
   try {
       funktion1();
       funktion2();
       ...
   } 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 << "Sonstige Exception" << std::endl: 
  };

Das erhöht die Sicherheit, dass eine Ausnahme nicht ungefangen vorbeifliegt. Rein aus Erfahrung

const hat keinen effekt. exceptions sind grundsätzlich CopyConstructible und werden als kopie weitergereicht. und sind somit immer non-const verfügbar. -- (nicht signierter Beitrag von 85.214.83.222 (Diskussion | Beiträge) 21:46, 13. Sep. 2009 (CEST))

"Anwendungen ohne eigene Benutzeroberfläche werden immer abgebrochen."

Das stimmt nicht ganz. Unter Java beispielsweise werden Programme erst beendet, wenn alle Programmthreads beendet sind. Ausnahmen sind ggf. Timer- oder Daemon-Prozesse, bei deren Instanzierung festgelegt wurde, dass sie mit dem Beenden aller anderen Threads ebenfalls gestoppt werden sollen.

  public static void main(String[] args) {
    new Thread() {
      public void run() {
        throw new RuntimeException(); // Fehler im Sekundär-Thread
      }
    }.start();
    synchronized(this) {
      this.wait();
    }
  }

  public static void main(String[] args) {
    new Thread() {
      public void run() {
        synchronized(this) {
          this.wait();
        }
      }
    }.start();
    throw new RuntimeException(); // Fehler im Haupt-Thread
  }

--Lazer erazer 10:41, 25. Okt. 2010 (CEST)

Satz entfernt, abwarten, was die Sichtung sagt. --Ch0peng (Diskussion) 00:58, 15. Mär. 2017 (CET)

LISP

Hinweis: In LISP gibt es das auch [1]. (nicht signierter Beitrag von 62.180.72.183 (Diskussion) 14:17, 30. Nov. 2010 (CET))

Trap

Trap führt in diesen Artikel, wird hier aber nicht erklärt.

• Kurz: "A trap is a software-generated interrupt caused either by an error or a user request." (Quelle: Skript zur Vorlesung Betriebssysteme am KIT)
  • Steht in direktem Widerspruch zu dem Text unter Trap. Ich muss mal schauen, ob ich da bessere Quellen finde.
• Ein Trap sorgt dafür, dass in den Kernel-Modus gesprungen wird.
• Ein Trap stellt eine Möglichkeit dar System Calls zu implementieren.
• Springt an eine vordefinierte Stelle im Kernel.
• int80 sei auf x86 als trap missbraucht worden ... allerdings habe ich das nur in Tutorien gehört.

--MartinThoma 12:09, 5. Nov. 2011 (CET)

Mehrfachbedeutung von Exception

Exception hat mindestens zwei Bedeutungen:

• Die Ausnahmebehandlung im Programmcode (scheint mit diesem Artikel gemeint zu sein)
• Systemnahe Fehler (vgl. Interrupt)

Die Weiterleitung von Exception sollte also entweder Aufgelöst oder besser durch eine Übersichtsseite ersetzt werden. --MartinThoma 15:24, 5. Nov. 2011 (CET)

Grafik

Was soll die Grafik aussagen? Sie wird weder erklärt, noch wird in irgendeiner Weise darauf eingegangen. In der momentanen Form trägt sie nur zur Verwirrung bei, eine Aufklärung bezüglich Exceptions und Interrupts (oder eine Referenz dazu) wäre IMHO auf jeden Fall notwendig. --213.33.116.117 15:55, 13. Jun. 2012 (CEST)

Defekter Weblink

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieses Fehlers finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://archives.java.sun.com/cgi-bin/wa?A2=ind9901&L=rmi-users&F=P&P=36083
  • Netzwerk-Fehler (6) andere Artikel, gleiche Domain
  • Im Jahr 2012 bereits defekt gewesen.http://giftbot.dwl.invalid/http://archives.java.sun.com/cgi-bin/wa?A2=ind9901&L=rmi-users&F=P&P=36083

– GiftBot (Diskussion) 02:42, 28. Nov. 2015 (CET)

Swift

Sicher, daß Swift Exceptions enthält? Ich meine gelesen zu haben, daß Swift die Exception nicht nach oben (also durch den Caller-Stack hindurch) propagiert. Wäre das dann dennoch ein Exception-Mechanismus? – Torsten Bronger (Diskussion) 18:13, 27. Feb. 2017 (CET)

In der offiziellen Doku zum Error Handling von Swift 3 wird die im Quellcode-Beispiel dargestellte Fehlerbehandlung nicht als Exception bezeichnet, weil es technisch anders realisiert ist: "Unlike exception handling in many languages [...] error handling in Swift does not involve unwinding the call stack, a process that can be computationally expensive. As such, the performance characteristics of a throw statement are comparable to those of a return statement." Meiner Meinung nach ist es für einen Exception-Handling-Mechanismus aber unerheblich, wie er technisch realisiert ist; es kommt darauf an, dass der Programmierer Fehler (weiter-)werfen und fangen kann. Dies deckt sich auch mit der Erklärung im Abschnitt 1 ("Strukturierte Ausnahmebehandlung") im Artikel. (nicht signierter Beitrag von Ston~dewiki (Diskussion | Beiträge) 21:31, 27. Feb. 2017 (CET))

Beispiele aus verschiedenen Programmiersprachen

Ich finde es überflüssig hier Beispiele aus mehreren Programmiersprachen hinzupflastern. Um das Paradigma zu kapieren langt ein maximal zwei Beispiele. Ich werd das demnächst anpassen, wenn es keine Einwände gibt --Ch0peng (Diskussion) 01:00, 15. Mär. 2017 (CET)

@Ch0peng: Ich stimme dir zu. Die Auswahl der Programmiersprachen könnte auf Basis des TIOBE Index getroffen werden. Ich würde Modula-2 und Perl entfernen; die anderen befinden sich in den Top 10. Außerdem sollten die Beispiele von der Länge her angeglichen werden. --Trustable (Diskussion) 09:02, 15. Mär. 2017 (CET)

+1 Klingt gut --Ch0peng (Diskussion) 12:16, 15. Mär. 2017 (CET)