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:
und in der Klasse dann:
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):
val = myObject.doStuff()
if myObject.getErrMsg <> "" then
msgbox myObject.getErrMsg(), 16, "SYSTEMFEHLER"
exit sub
end if
und in der Klasse dann:
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
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.
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
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.
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.