Informatik, worin liegt der unterschied zwischen exceptions und assertions?
Worin liegt der Unterschied zwischen exceptions und assertions? Beide werden ja wie bekannt für Fehlerbehandlungen verwendet, aber was ist der unterschied? Wann wird was verwendet?
6 Antworten
Eine Exception ist ein unerwarteter Fehlerzustand. Dieser kann immer auftreten. Beispielsweise: Du öffnest eine Datei, liest daraus und plötzlich zieht der User die USB-Platte ab. Peng - Exception.
Eine Assertion ist eine Sicherstellung von Voraussetzungen im Rahmen des Debug-Prozesses.
Beide führen, wenn sie nicht behandelt werden, zum Abbruch des Programms. Der wesentliche Unterschied ist:
Exceptions sollten behandelt werden (ggf. durch geordnetes Beenden der Anwendung oder eine Fehleransicht, etc.). Code sollte so programmiert sein, dass Exceptions, die auftreten, erkannt und abgefangen werden. Aber: Wenn Exceptions auftreten, dann sollte der Code möglichst so umgestaltet werden, dass diese nicht mehr auftreten - falls möglich. Niemals sollten Exceptions verwendet werden, um den Programmfluss zu steuern.
Assertions funktionieren nur in der DEBUG-Version des Codes (zumindest sollte das so sein) und stellen ein Mittel dar, um korrekten Code zu schreiben. Im Runtime-Code sollten Assertions gar nichts tun, bzw. vom Compiler gar nicht eingebunden werden/von der Runtime nicht ausgewertet werden. Bei Ausführung des Codes im Debug-Modus würde bei fehlschlagender Assertion die Ausführung an der Stelle abgebrochen wie bei einem Breakpoint und man kann zurückverfolgen, warum die Assertion fehlgeschlagen ist.
Andere Begriffe für Assertions sind auch Pre- und Post-Conditions. Vor einem Algorithmus müssen bestimmte Voraussetzungen gelten und nach seiner Ausführung auch. Das kann man mit Assertions einfach prüfen.
Eine Invariante dürfte ja durch den Algorithmus nicht verändert werden. Pre- und Post-Conditions wären aber beispielsweise:
assert(list.Count > 0) // Die Liste muss Elemente enthalten
sortiere(list)
assert(liste ist sortiert) // Prüfe, ob sortiere auch wirklich sortiert hat
Natürlich sollte dann auch nach wie vor gelten, dass die Anzahl der Elemente der Liste am Ende dieselbe ist, wie die Anzahl der Elemente am Anfang. Das wäre dann eine Invariante.
Das mein ich ja, die Bedingung die man mit Assertions prüft soll eine Invariante sein.
Ist das so vorgesehen? Mein obiges Beispiel zeigt doch gerade, dass man beliebige Conditions prüfen kann - auch natürlich Invarianten.
Ja ist es. Assertions wurden speziell dafür eingeführt (man kann aber auch beliebige andere Bedingungen prüfen, da der Compiler ja nicht unterscheiden kann zwischen Invarianten und Nicht-Invarianten)
Gut. Dann einigen wir uns doch darauf, dass Assertions als Mittel zur Prüfung von Invarianten eingeführt wurden, aber generalisiert zur Prüfung jeglicher Bedingungen genutzt werden können.
Assertions dienen eher zur Verifikation von Programmcode (Tut meine Methode das was Sie tun soll?). Hierfür werden Invarianten aufgestellt und in einer Assertions niedergeschrieben.
Exceptions hingegen dienen nicht dazu die Korrektheit eines Programmcodes zu verifizieren, sondern lediglich die Rahmenbedingungen zu überprüfen (Ist der übergebene Parameter gültig?)
Der größte Unterschied ist das Assertions bloß im debug fliegen nicht aber im Release.
Exceptions nimmt man bei Fehlern auf die man keinen Einfluss hat. Z.b. ne Datei ist nicht da. Und die man auch nicht an Ort und Stelle behandeln kann sonder sich der aufrufen weiter oben drum kümmert.
Assertions werden genutzt um zu schauen ob der Code auch wirklich das macht was er soll. Ist quasi eine Behauptung des Entwicklers das die Bedingung zu dem Zeitpunkt im Code wahr zu sein hat.
Wird genutzt wenn halt eine Bedingung erfüllt sein muss und die Entwickler dafür sorgen müssen das diese erfüllt ist.
Z.b. wenn Konfigurationswerte fehlen. Etc.
Und da asserts nur im debug fliegen interessiert es den Benutzer des Programmes später nicht.
Ich danke dir für eine schnelle Antwort. Also sind Assertions sowas wie ein Wahrheitswert die true oder false zurückliefern und dazu verwendet werden zu schauen ob die Methode das tut was sie tuen soll?
Ne nicht ganz.
Meist ist es eine Methode z.b. Debug Assert(Bedingung,Nachricht)
Wenn die Bedingung falsch ist wird eine Nachricht hoch gebracht und man kann direkt in den Code einspringen wo die Assert hochkommt.
Asserts sind überall da nützlich wo Fehler nicht so schlimm sind im Release aber diese im debug beim testen auch von anderen Entwicklern gesehen werden können.
Auch um Race conditions auf zu zeigen sind sie nicht schlecht.
Vor allem aber, um vermeidbare Fehler bereits im Vorfeld zu erkennen! Exceptions sind meist unvermeidbar (zumindest, wenn man es richtig macht).
Unter einer Assertion versteht man Code, der Daten auf eine Bedingung hin prüft, von der man denkt, sie müsse an dieser Stelle im Programmablauf erfüllt sein.
Liefert die Assertion TRUE, ist alles OK, um man kann weiterrechnen.
Liefert die Assertion aber FALSE, weiß man, dass Weiterrechnen keinen Sinn macht und der Programmablauf abgebrochen werden muss. Technisch implementiert wird so ein Abbruch durch "Werfen einer Exception".
Name, Typ und/oder eine der Exception mitgegebene Fehlerbeschreibung erklären woran das Vorliegen des Fehlers erkennbar war.
Bei einer Exception tritt zur Laufzeit ein Fehler auf, den du nicht erwartet hast. Es ist eine Fehlerbehandlung notwendig, um das Programm weiterlaufen lassen zu können, der Fehler muss behandelt werden.
Bei einer Assertion hingegen prüfst du aktiv zur Laufzeit, ob ein Objekt einen bestimmten Wert hat oder sich in einem festgelegten Bereich bewegt. Das ist dann insbesondere beim Testen und Debugging deines Codes hilfreich.
Zusammenfassend, bei einer Exception tritt ein Fehler auf, wird dir entgegen geschmissen, den du behandeln musst, sonst geht es nicht weiter, während du bei einer Assertion selber prüfst, ob ein Objekt ein bestimmtes Prädikat, eine Bedingung, erfüllt, welches du selber wählst.
Im mathematischen Sinne nennt man diese auch Invarianten