Fehlerbehandlung bei Konstruktoren

[oz]

Hallo Forum,

Ich habe eine Klasse in LotusScript.
Die Klasse hat einen Konstruktor.
Zusätzlich hat die Klasse selbstverständlich einige Methoden.

Public Class MeineKlasse
Sub New()
....Hier tut der Konstruktor etwas, was auch schief gehen kann.
End Sub
End Class

Folgendes Problem stellt sich mir:
Im Konstruktor passieren Dinge, die auch schief gehen können. In diesem Fehlerfall würd ich mir wünschen, daß die Klasse "Nothing" ist.

Dim meineKlasse As New MeineKlasse

Im Fehlerfall müßte also die Variable meineKlasse "Nothing" sein, also

If meineKlasse Is Nothing Then
   Exit....
Else
   meineKlasse.methode1
End If

Somit würden keine Methoden an einer "NULL" instanz einer Klasse aufgerufen.
Wie kann ich das Errorhandling im Konstruktor machen? Kann ich eine Klasse im Konstruktor "Nothing" setzen?

Vielen Dank für Eure Hilfe

Gruß
Oz

[koehlerbv]

Mittels der Delete-Anweisung kannst Du ein bereits erzeugtes Objekt wieder in den Orkus befördern. Eigentlich sollte das also tun, was Du erreichen willst.

HTH,
Bernhard

[flaite]

Hier stehen sehr interessante Informationen zu Errorhandling allgemein drin:
http://www-128.ibm.com/developerworks/lotus/library/ls-DebugLS2/

Dieser Code.

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

[koehlerbv]

Axel, ich glaube, Kollege S. aus G. bei M. hat sich etwas missverständlich ausgedrückt. Er will eventuelle Errors so handeln, dass ein eventuell schon aufgebautes Object dann wieder vernichtet wird und andere Routinen somit dieses Object auf "Nothing" überprüfen können.

Bernhard

[animate]

Ich habe auch nicht so ganz verstanden, auf was Axel hinauswill, aber es hat mich auf die Frage gebracht, was man am Besten tut, wenn in der Sub New irgendwas schief geht.

Lösche ich mein Objekt dann wieder mit dem von Bernhard genannten
Delete Me

oder

erzeuge ich einen Fehler mit Error und fange diesen Fehler dort ab, wo ich das Objekt erzeuge?

Ich persönlich halte generell die zweite Alternative für geschickter weil es evtl. ja sein könnte, dass es mehrere Punkte gibt, die schief gehen können.
Bei der ersten Lösung weiß der Aufrufer nur, es ist was schief gegangen, bei der zweiten weiß er auch was und kann ggf. Gegenmaßnahmen einleiten.

[koehlerbv]

Warum nicht das eine tun, ohne das andere zu lassen, Thomas ? Ich würde auf jeden Fall beides machen ...

Bernhard

[flaite]

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.

Code

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.

[flaite]

Ok. nächster Versuch.
Das Objekt wird in einer anderen Routine benutzt.

Wenn das Objekt in einem inkonsistenten Zustand ist gibt es 2 Möglichkeiten:
1. Die Routine kann überhaupt kein sinnvolles Ergebnis mehr liefern.
Dann: Über Error Err, Error  die Fehlermeldung durchreichen.

2. Die Routine kann trotzdem weiterarbeiten.
Dann: Reaktion auf inkonsistenten Zustand in Objekt selbst verarbeiten.

Es ist ja sonst so ähnlich wie solche Funktionsaufrufe gegen SkriptLibs und die find ich auch nicht gerade übersichtlich.

res = myFunctionCall()
if res = "fehler" then

else

[oz]

Scheint, daß ich mit meiner Frage eine grundsätzliche Diskussion über Fehlerbehandlung in LotusScript losgetreten zu haben ;-)

@kennwort, das was du in 1. beschrieben hast ist mir die sympathischste Lösung. Auch die die am nächsten an das ExceptionHandling von anderen Objektorientierten Sprachen rankommt. Wenn also ein Fehler beim Instanziieren des Objektes auftritt wird der Fehler an den Aufrufenden weitergegeben. Der muss dann entscheiden was zu tun ist. Im zweifelsfall muss die ganze Aktion an  dieser Stelle abgebrochen werden.

Den Vorschlag den Status des Objekts in einer eigenen Property mitzuschleifen und abzufragen halte ich für nicht gut. Der Konstuktor hat ja genau denn sinn ein "gesundes" Objekt zu erzeugen. Wenn das schief geht, dann brauch ich gar nicht weiter zu machen.

Vielen Dank für die lebhafte Diskussion.

Gruß
Oz, oder für Berhanrd "Kollege S. aus G. bei M."