Domino 9 und frühere Versionen > Entwicklung

LotusScript-OO:Exception Field Pattern

<< < (2/2)

animate:
Welche Vorteile hat in deinen Augen denn diese Kombination?

Ehrlich gesagt halte ich auf den ersten Blick überhaupt nichts davon. Eben aus dem Grund, dass ich zwei Verfahren habe, die ich anwenden muss/kann.

Semeaphoros:
Das ist ein Argument, mehr kann ich dazu im Moment auch nicht sagen. Ich kenne Systeme (ausserhalb von Notes), wo das so gehandhabt wird. Bei mir ist das in einer Brainstormingphase, daher kann ich Dir nicht wiklich eine schlüssige Antwort geben.

Marinero Atlántico:

--- Zitat von: Thomas Völk am 09.06.05 - 07:29:40 ---mit der Fehlerbehandlun in deiner Klasse "löschst" du den Error ja. Er ist also nicht mehr für den Client verfügbar. Deshalb muss der Client bei dir diese Prüfung machen.

Wenn du stattdessen den Error in deiner Klasse mit ein paar Daten anreicherst und dann weitergibst, dann kannst du im Client auch ganz normal dein On Error Statement benutzen.


--- Code: ---Sub doIt

      On Error Goto errHandler
      Exit Sub

errHandler:

      Error Err, Error & |-| & Getthreadinfo(1) & |:| & Erl

End Sub

--- Ende Code ---

--- Ende Zitat ---
8)

Das ist imho viel besser und ich wußte nicht, dass man den Error anreichern kann.
Gut das wir drüber geredet haben.
Erinnert ein bischen an Exception Chaining in Java, wo man einer Exception in eine andere Exception wrappern kann (Throwable in Kontruktor übergeben).
Ist natürlich völlig in der Verantwortung des Entwicklers, die Exception *irgendwo* per nicht-weiterreichenden Errorhandler abzufangen. Das ist aber imho völlig in Ordnung.
In Java erzwingt der Compiler ja bei Checked Exceptions, dass sie irgendwo im Callstack gecatched werden und ansonsten müssen sie explizit per throws weitergereicht werden.

AFAIK hat aber C# genau dieses Feature von Java nicht übernommen. Bruce Eckel hat sich dazu kritisch geäussert und Rod Johnsons Genöhle über zu viele Checked Exceptions und SQLException im speziellen finde ich sehr schlüssig.

Gruß Axel

Semeaphoros:
Stimmt schon, dieses Weiterreichen des Fehlers hat - bei richtiger Handhabung - durchaus etwas sehr interessantes.

animate:

--- Zitat von: Marinero Atlántico am 09.06.05 - 11:00:26 ---Ist natürlich völlig in der Verantwortung des Entwicklers, die Exception *irgendwo* per nicht-weiterreichenden Errorhandler abzufangen. Das ist aber imho völlig in Ordnung.

--- Ende Zitat ---

Das ist nicht mal nötig. Wenn du den Fehler immer nur weiterreichst, dann wird er letztendlich von Nozes angezeigt, wie der bekannte 91 Object variable not set, z.B. Das ist natürlcih nicht so schön. Wie mans besser macht hat der Autor im selben Artikel beschrieben. Eine wunderschöne Lösung, wie ich finde.

Ich habe den Artikel mal rausgesucht, er ist hier.

Kann nur jedem, der ihn nocht nicht kennt, empfehlen, den mal zu lesen.

Navigation

[0] Themen-Index

[*] Vorherige Sete