LotusScript-OO:Exception Field Pattern

[Marinero Atlántico]

Hi,

wenn ich Klassen in LotusScript Klassen schreibe, das beunruhigenste für mich ist wirklich der Exception Mechanismus von LotusScript. Ich hasse es, wenn Fehler nicht abgefangen werden und ich dann auch direkt die Zeilennummer des Fehlers geliefert bekomme.

LotusScript hat aber nicht diesen Exception Mechanismus von Java, wo der Throwable den Stack der Methoden hochgereicht wird.

Ich hab ClientCode:

Code

myObject.doStuff()

und in der Klasse dann:

Code

myClass 

function doStuff() As Integer

Aus dem Client-des-Objekts-code gibt es imho nur diesen Weg an die Fehlermeldung ranzukommen (ohne mit speziellen return values zu arbeiten, was ich auch hasse):

Code

val = myObject.doStuff()
if myObject.getErrMsg <> "" then
 msgbox myObject.getErrMsg(), 16, "SYSTEMFEHLER"
 exit sub
end if 

Wenn man das bei jeder Methode mit einem gewissen Fehlerrisiko macht, cluttered das natürlich den Client-Code voll mit Zeugs.

und in der Klasse dann:

Code

myClass 


errMsg As String

Sub new () 
errMsg = ""
end sub

function doStuff() As Integer
doStuff = 0
on error goto Fehler
// do Stuff


Finish: 
exit function
Fehler:
errMsg = |Fehler in "myClass.doStuff"| & Error$ & "(" & Cstr(Err) & ") in Zeile:" & Cstr(err)
goto Finish 
end function

function getErrMsg() 
getErrMsg = errMsg
end function 

Ja richtig. Mit diesen "seltsamen" Properties arbeite ich auch nicht. Das ist aber mein Fehler und ich will mir das angewöhnen. ErrMsg ist ziemlich wahrscheinlich ein guter Kandidat für Properties.

Irgendwelche Meinungen?

Gruß Axel

[Semeaphoros]

Meinung ja, generelle Lösung nein.

Das ist ein Problem, liegt aber weniger an LotusScript, als vielmehr an der zugrunde liegenden Unart von Basic, wovon LS ein Dialekt ist. Ich bin mir da auch nicht schlüssig, wie man das am besten löst, es gibt auch hier verschiedene Ansätze. Tatsächlich wäre der Gang über Properties naheliegend, das würde das Basic-Verhalten, den Fehler in Systemvariablen zur Verfügung zu stellen, imitieren.

[Marinero Atlántico]

War mir auch nicht sicher, ob das vielleicht nicht ein Anti-Pattern ist. Hätte das vielleicht deutlicher ausdrücken können.
Aber es freut mich, dass du zumindest genauso wie ich zu sehen scheinst, dass dort ein Problem ist.
Patterns sind ja auch keine generellen Lösungen sondern solutions in a context. Und in bestimmten Kontexten, kann das mehr Nutzen als Kosten verursachen.

Besser ist:in den Declarations eine globale private Variable errMessage ausserhalb jeder Klasse und darauf eine public getter-Funktion ausserhalb jeder Klasse.
Dann kann man das direkt für mehrere Klassen verwenden, da man häufig mehrere Klassen in den Declarations hat.

Code

private errMessage as String

public getErrMessage as String () 
getErrMessage = errMessage
end function

myClass




Sub new ()
errMsg = ""
end sub

function doStuff() As Integer
errMsg = ""
doStuff = 0
on error goto Fehler
// do Stuff


Finish:
exit function
Fehler:
errMsg = |Fehler in "myClass.doStuff"| & Error$ & "(" & Cstr(Err) & ") in Zeile:" & Cstr(err)
goto Finish
end function

[animate]

ich weiß nicht ob ich die Problemstellung verstanden habe, also bitte korrigiere mich, wenn das hier nix zur Lösung beiträgt.

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

Mit dieser Technik kannst du den Fehler & den CallStack bis nach ganz oben reichen (Initialize z.B.)

Das ganze ist nicht auf meinem Mist gewachsen, sondern das habe ich mal in einem Artikel über Debugging von Andre Guirard auf notes.net gelesen. Ich finds gut.

[Semeaphoros]

Rocky Oliver hat in seinem Lotusphere Errorhandling Vortrag unter anderem auch diese Strategie vorgestellt. Ich denke, eine Kombination der Verfahren etwa nach dem Muster: Warnung, also ErrMsg füllen und den Errorstatus löschen, FatalError, also Errorstatus beibehalten und zur rufenden Routine zurückgeben wäre ideal, schade dabei ist insbesondere, dass so etwas nicht für die gesamte Klasse definiert werden kann, also auf der Ebene der einzelnen Methoden abgehandelt werden muss. Anders ausgedrückt, mir fehlt vor allem eine OnError Methode auf der Klassenebene. Ich denke, das ist auch das Manko, das Axel mit der globalen Variable, in seinem Fall sogar klassenübergreifend (was mir persönlich nicht so gefällt) vor allem löst.

[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]

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

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]

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.

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.