Schon wieder so ne Glaubensfrage
.
Kurz zur Theorie: Exceptions stellen, wie der Name schon sagt, Ausnahmen dar, also Abweichungen vom Standardverhalten. Kurzes Beispiel: Kommunikationsprotokolle. Diese legen einen Ablauf der Kommunikation fest. Möglich sind z.b. Abweichungen vom Protokoll, dann ist es durchaus legitim, dass die Anwendungen eine eigens definierte ProtocolViolatedException oder sowas wirft (Name gerade frei erfunden), oder z.b. eine entsprechende Exception im Falle eines Verbindungsabbruchs (technischer Fehler, ganz anderes Niveau!).
Man erwartet, dass die Kommunikationspartner sich an das Protokoll halten und die Verbindung nicht wegbricht - Exceptions werden also in
unerwarteten Fällen geworfen.
Auf dein Beispiel übertragen:
Wenn du weißt, dass du irgendwann an die Grenzen eines Arrays stößt, solltest du versuchen, dein Programm ohne Exceptions robust hinzukriegen. Die Länge eines Arrays ist zu jeden Zeitpunkt festellbar, das ist also durchaus möglich.
Die Exception würde ich nur dann schmeißen, wenn du nicht erwartest, dass du an die Grenzen kommst (aus welchem Grund auch immer, z.b. weil ein Auswahlmechanismus dir ein falsches Array geliefert hat und du nun glaubst, du operierst auf einem vollkommen anderen oder sowas.)
Man kann also mit einer Exception signalisieren, dass man dieses Ereignis nicht erwartet hat. Inflationäre Verwendung von Exceptions bringt das Problem mit sich, dass dieser Aspekt entwertet wird. Ich habe schon erlebt, dass man einfach neue Exceptions einführt, um eben zwischen erwartet / unerwartet unterscheiden zu können - dann muss man aber evtl prüfen, wann welche Exception geworfen werden soll, und da hätte man es gleich ganz ohne machen können
Ein Pro-Argument: Exceptions stellen ein einheitliches System zu Signalisierung von Abweichungen dar - Viele erfinden da da Rad neu und signalisieren sowas über irgendwelche Zustandsvariablen, die nur unnötig die Komplexität der Software hochschrauben ("komplex" as in "für den Menschen schwierig zu verstehen", nicht im Sinne einer Laufzeit).
Contra-Argumente (bitte selbst entscheiden, wie wichtig das ist):
1. try/catch macht den Code unleserlich. Man muss einige Zeilen schreiben, die Einrückungen entsprechen nicht mehr dem eigentlichen Codeablauf usw.. Insbesondere, wenn man mal try/catch schachteln muss, wird das ein Horror. Natürlich ein schwaches Argument, an sollte nicht unbedingt schlechtes SoftwareDesign aufgrund von besserer Lesbarkeit akzeptieren.
2. Exceptions sind teuer, was Laufzeit und Ressourcen angeht. Hier gilt das Gleiche: Lieber etwas Zeit und RAM fressen, als in wilde Frickeleien verfallen. Es gilt natürlich abzuwägen, welcher Punkt überwiegt (z.b. eine kleine Frickelei für eine große Ressourcenersparnis, sowas kommt aber selten vor)
Man muss auch selbst entscheiden, welcher Anforderung man folgt: Entscheidet man anhand jedes Einzelfalls, ist man flexibel, aber die Konsistenz der Codes sinkt. Hält man sich streng an eine Linie, muss man Exceptions entweder ignorieren oder permanent damit um sich schmeißen, beides funktioniert kaum.
Weil ichs noch vorhin vergessen hab: Ein wichtiger Punkt ist: Kann sich die Methode, die evtl. eine Exception generiert, sich selbst um deren Handling kümmern?
Im Beispiel der Kommunikation signalisiert man nur der Anwendeung, was schiefgegangen ist, damit diese geeignet reagieren kann, denn das kann die Methode evtl garnicht wissen.
Ist dagegen ausgeschlossen, dass sich das Verhalten der Software anhand von Informationen definiert, die die Methode nicht kennt, dann sollte sie sich selbst um das Handling kümmern und keine Exception werfen, denn damit versteckt sie die Komplexität nach außen hin.
Und weiterhin wirft man gerade bei Prototypen & Mock-Ups gerne mit Exceptions um sich, da es evtl lange dauert, bis man eine komplexe Methode geschrieben hat, die sich (korrekt) um die Fehler kümmert. Dann nimmt man Exceptions als temporäre & schnelle Lösung in Kauf, in der Absicht, sich später mal drum zu kümmern.
![[HaBo]](/styles/default/logoklein.png){kind=small}
