exception handling - wie am Besten?

Re: exception handling - wie am Besten?

Hey Legxis,

wie ich schon meinem Beitrag erwähnt hab, finde ich die genannte Methode
catch fehler1
--> tue was

catch fehler2
--> tue was2

catch fehler3
-->tue was3

sehr angenehm. Es geht ja nicht nur um mögliche unterschiedliche Feherlausgaben für den Benutzer, sondern auch darum wie sich dein Programm im Fehlerfall zu Verhalten hat:
- Müssen DB Operationen zurückgenommen werden (Rollback)?
- Müssen andere Aufräumarbeiten durchgeführt werden(Werte initial setzten)?
- etc...

Meine Erfahrung mit Exception sind aber auch noch sehr begrenzt. Daher die Bitte an das Forum. Ergänzungen etc bitte

Grüße 4Byte

Re: exception handling - wie am Besten?

Legxis hat geschrieben:Während eines anderem Threads sind wir auf das Thema Ausnahmebehandlung gekommen und mir ist aufgefallen, dass es bei mir da noch was zu tun gibt.
Ich habe umhergesucht und viele viele verschiedene Möglichkeiten gesehen, Exceptions zu behandeln, und das hat mich nur noch mehr verwirrt.
Deshalb wollte ich mal fragen, wie ihr das macht, was die beste Methode ist, etc. am besten mit Codebeispiel.

So habe ich es bisher am Meisten gesehen und dieses Beispiel verstehe ich auch, aber ist das auch ein guter Weg, die Ausnahme zu behandeln?

Es gibt mehrere Varianten, je nachdem wie deine Architektur aussehen soll. Dein Beispiel ist leider nicht sehr gut gewählt.

Grundsätzlich muss man sich fragen, ob alle Fehler tatsächlich von der jeweiligen Methode / Aufrufstelle behandelt werden sollen. Ein pauschaler Catch auf CX_ROOT macht nur Sinn, wenn ein Dir unbekannter Fehler tatsächlich keine Auswirkungen auf den weiteren Programmlauf haben soll, oder in dem Fall gezielt das Programm beendet wird.


Der Vorteil der klassenbasierten Ausnahmen ist, ja, das der Fehler entlang der Aufrufhierarchie weiter gegeben wird. Wenn man vernünftig atomar arbeitet, würde so ein CX_ROOT nur an oberster Ebene deiner Programmhierarchie behandelt werden müssen, was dem DRY und KISS Prinzip entspricht.

Es gilt also die Fragen zu stellen und zu behandeln : Macht bei einem Fehler in einer unteren Hierarchie es noch Sinn, das Programm fortzusetzen ? Kann die Hierarchieebene auf der ich gerade bin, entscheiden, was mit dem Fehler zu tun ist ?

Ist dein Coding Teil des Hauptprogrammes ist das so ja noch ok. Es verhindert einen allgemeinen Absturz des Programmes.
Das Abfangen bekannter Fehler mit einer Unterscheidung durch mehrere CATCH Anweisungen macht nur Sinn, wenn tatsächlich in den Einzelfällen eine unterschiedliche
Behandlung erfolgen soll. Ansonsten kann man ruhig zusammenfassen. In deinem Fall würde CX_ROOT ja nur gecatcht, wenn ein anderer als die beiden spezifischeren Fehler auftritt.

Ist dein Aufruf jedoch in einer Methode z.b. eines Services, sollte entweder a) die Service-Methode alle bekannten Fehler die zu behandeln sind auch in ihrer Definitionen nach außen sichtbar propagieren. Der Aufrufer kann dann selbst entscheiden, was er damit macht und wieder selber unterscheiden ( in dem Fall würde innerhalb der Methode gar nichts gecatcht werden ) oder b) die Methode eine übergeordnete Fehlerklasse propagieren und eine Iteration über das Previous-Attribut erfolgen.

Eine Exception kann ja auch RESUMABLE sein, wenn z.b. das Ganze in einer Schleife steckt und ich gern durch eine gesamte Liste iterieren möchte um entweder Fehler gesammelt auszugeben oder mit den Positivfällen, weiter arbeiten zu können.

Grundsätzlich kann ein untergeordneter Bestandteil ( z.b. die Methode eines Services ) selten entscheiden ob das umliegende Programm weiterarbeiten kann, wenn der Fehler existiert. Also würde ich mir gut überlegen ob und wo ich CX_ROOT catche. Warum alte ABAPler ( zu denen ich auch gehöre ^^ ) OO oft skeptisch gegenüber stehen ist,
nach meiner Meinung, dass mehr Zeit in ein Programmdesign gesteckt werden muss und sollte.

Gruß,

GTO

PS: Das Naming mit ex_ref finde ich subobtimal. Es wird ja schliesslich ein Objekt erzeugt und keine Referenz. Daher wäre obj_cx o.ä. besser .