Domino 9 und frühere Versionen > Entwicklung

Fehlerbehandlung bei Konstruktoren

<< < (2/2)

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.

--- Ende Code ---


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."

Navigation

[0] Themen-Index

[*] Vorherige Sete