Hier stehen sehr interessante Informationen zu Errorhandling allgemein drin:
http://www-128.ibm.com/developerworks/lotus/library/ls-DebugLS2/
Dieser Code.
Sub New
On Error Goto Repeater
' put the rest of your code here.
Exit Sub ' or Exit Function if this were a function
Repeater:
Error Err, Error & {
//} & Getthreadinfo(1) & {:} & Erl
' 1 = LSI_THREAD_PROC
End Sub
Du kannst mal versuchen. Statt Repeater new. Das Objekt wird ja irgendwo initialisiert und da kannst du das dann abfangen.
Es gilt übrigens als schlechte Praxis zu viel Funktionalität in den Constructor zu packen. Falls umfangreichere und riskantere Initialisierungen gefragt sind, erstelle ich immer eine zweite Methode init(). Da kannst du diese Art des Error-Handlings natürlich auch einbauen.
Gruß Axel
Ein Objekt hat immer Client-Code der dieses Objekt erzeugt, Methoden aufruft etc.
Client Code heisst einfach: Dieser Code ist praktisch ein Client dieses Objekts.
Falls es Inkonsistenzen in dem Objekt selbst gibt, dann ist wirklich delete me eine Möglichkeit.
Ich würde aber einen Weg suchen, um den Client aktiv zu benachrichtigen. Und der Client code müsste dann einen Weg finden, um die ganze Routine zu beenden.
Was hätte ich sonst von dem delete me. Ich müsste bei allen Aufrufen auf das Objekt nachfragen, ob das Objekt nothing ist.
Falls ein "nothing" Objekt doch irgendwie brauchbar ist, würd ich es nicht auf Nothing setzen, sondern in einen speziellen State (State ist die Menge aller Instanzvariablen).
So wäre die Information über den speziellen State in dem Objekt gekappselt. Mit nothing müsste das Wissen um den speziellen Nothing-State eine Ebene nach unten verschoben werden (der client code).
Du kannst die Info über die fehlgeschlagene Initialisierung ja auch in dem Objekt selbst halten.
Init as integer ' set in constructor
function methode1 As String ()
if init = false then return "ERROR"
.... normales zeugs.
Diese ständige Abfrage auf Nothing in dem Code der das Objekt benutzt ist nicht so gut.
In Pattern Land gibt es dagegen z.B. extra das relativ beliebte NullObjekt Pattern (vom Typ einer extra Sub-Klasse, die gar nichts tut).
Man müßte aber wirklich den Rest des codes kennen, um vernünftige Aussagen zu treffen.
Wenn ich jedenfalls zu viele if else Abfragen habe, ist es nicht gut (meine Faustregel).
Und jedesmal Abfrage auf if not nothing ist ein Kandidat für "zu viel".
Axel
Ich hoffe das ist verständlich.