Fehlerbehandlung - Umgang mit Exceptions

[Mr_G]

Hallo zusammen,
ich schreibe gerade eine Klasse und muss mich um die Fehlerbehandlung kümmern. Ich hatte eigentlich vor ein Event zur Verfügung zu stellen, durch das man auf Fehler reagieren kann. Dennoch dachte ich, es wäre vielleicht sinnvoll eigene Exceptions einzubauen falls der Programmierer die gebotene Möglichkeit nicht nutzt.

Das Problem: Wenn ich nun sowohl das Event auslöse als auch eine Execption werfe bekommt der User evtl. zwei Meldungen wenn man im OnError-Event auch eine Meldung ausgeben will.

Ich frage mich nun ob das gegenläufige Ansätze sind? Ich zwinge eben den Programmierer mit Exceptions try...except-Blöcke zu nutzen oder er muss das Event nutzen.
Meine Idee das Problem zu umgehen wäre ein Flag zu nutzen und die Exceptions nur auszulösen, wenn dieses gesetzt ist.

Meine Frage: Wie macht man es denn richtig bzw. was ist guter Programmierstil? :coder:

[Luckie]

Vergiss die Ereignisse und arbeite mit Exceptions.

[Mr_G]

Sprich ein OnError-Event ist hier eher der schlechte Stil?
Ich muss zugeben, dass mich das etwas wundert. Ich habe so ein Event schon öfter gesehen und genutzt.

[Apollonius]

In den meisten Fällen muss ich Luckie zustimmen. Sinnvoll halte ich ein OnError nur bei solchen Dingen wie Sockets, wo Fehler aufgrund ihrer asynchronen Natur schwer zu fangen sind. Sonst verleiten solche Events nur zu schlechtem Stil, d.h. einem globalen Handler ("Es ist ein Fehler aufgetreten"). Wenn der Programmierer Code aufruft und dieser Aufruf fehlschlägt, dann muss ihm der Fehler am Aufrufort um die Ohren gehauen werden! Ohne Kenntniss der Aufrufsituation kann sonst keine gute Fehlerbehandlung stattfinden.

[mkinzler]

Zitat:

Sonst verleiten solche Events nur zu schlechtem Stil, d.h. einem globalen Handler ("Es ist ein Fehler aufgetreten").

Ist aber bei Exception genauso- Auch diese kann man recht global abfangen

[Mr_G]

Oje... genau hier gehts los: Es handelt sich um eine Klasse zur Kommunikation via Sockets.
Was mach ich denn nun?

[mkinzler]

Dann wäre ein Event ok.

[Luckie]

Es ist umständlich. Der Programmierer muss dann immer noch eine Ereignisbehandlungsroutine schreiben. Mit Exceptions kann er den Fehler in der Routine abfangen in der er auftritt.

Und ausserdem führt das zu einem ewigen hin und her gescrolle im Code. Und wenn du dem Fehlererignis einen Fehlercode mitgibst, hast du in der Ereignisbahendlungsroutine irgendwann mal eine Ellen lange case-Abfrage, das ist auch unschön.

[Apollonius]

Zitat:

Zitat von mkinzler

Zitat:

Sonst verleiten solche Events nur zu schlechtem Stil, d.h. einem globalen Handler ("Es ist ein Fehler aufgetreten").

Ist aber bei Exception genauso- Auch diese kann man recht global abfangen

Schlimm genug, dass sich diese Praxis in Delphi so gut wie durchgesetzt hat. Ein Event zwingt einen praktisch dazu.

[Mr_G]

Ich hab da noch eine Idee... die ist aber glaube ich sehr "unsauber":
Das Event bekommt einfach einen var-Parameter mit dem es signalisieren kann ob es den Fehler behandelt hat (so im Stil con CanClose). Wurde der Fehler behandelt wird keine Exception geworfen, falls nicht werfe ich eben die Exception.

[Apollonius]

Die Sockets aus ScktComp machen es genau so.

[Mr_G]

Hab mir die Unit mal angesehen... die machen das mit dem ErrorCode so ähnlich. Das sind ja die alten Socket-Komponenten, oder?
Also wenn das kein unglaublich schlechter Stil ist, würde ich das einfach auch so machen.

[Apollonius]

Bei den Sockets finde ich das in Ordnung, weil es eben asynchrone Exceptions sind, die erst mitten in der Nachrichtenschleife auftreten. Einen Try-Except-Block kann man dafür nirgendwo sinnvoll platzieren; man müsste global Application.OnException anzapfen, was keine gute Idee ist, weil sich so leicht mehrere Handler in die Quere kommen.

[Mr_G]

Ok! Vielen Dank für eure Antworten! :dp:

[Dezipaitor]

Ich sage, Exceptions sind die erste Wahl bei synchronen Events.

Fehler sollten immer ins Entwicklergesicht geschmettert werden :). Stille Fehler sind tödlich.