Domino 9 und frühere Versionen > ND8: Entwicklung

Kann sich eine Klasseinstanz selbst zerstören?

<< < (3/3)

flaite:

--- Zitat von: Tode am 25.11.14 - 16:02:24 ---Du machst aber ein "Resume"... und damit ist der Error "gegessen" und die aufrufende Funktion / Sub bekommt nie mit, dass da ein Fehler passiert ist...

--- Ende Zitat ---
Richtig. Mach Dir einfach in Base.logError(...) einen Breakpoint hinter dem Aufruf von ErrorHandler.logError(...)

Ausserdem sollte ein Konstruktor dafür da sein, eine Instanz in einen gerade brauchbaren Zustand zu bringen.
Faustregel: Möglichst wenig Code in Konstruktor.

Errorhandling wird nicht dadurch besser, dass Du es über 3 Methoden verteilst, die sich dann gegenseitig aufrufen. Das sieht zwar erstmal nett aus, verkompliziert aber in der realen Welt den code.
Eine Methode sollte nie gleichzeitig eine Exception loggen UND sie an eine weitere Methode weiterleiten. Immer eins von beiden.

Wenn Du genau darüber nachdenkst, kann so ein code eigentlich nur auf 2 Arten auf einen Error reagieren:
1. Der Anwendungsentwickler kann einen Weg finden, um den Ablauf trotzdem weiterzuführen.
2. Man gibt unterschiedliche Nachrichten an die Administratoren (loggen) und an den Anwender (Messagebox: Something went wrong).

Fall 2 ist wesentlich häufiger. Die Entwickler der Sprache Java führten sogenannte Checked Exceptions ein, die Anwendungsentwickler dazu bringen sollten, Punkt 1. Lösungen zu finden. Das ist aber meistens gar nicht möglich. Die Entwickler der Sprache führten checked Exceptions an Stellen ein, an denen sie völlig fehl am Platz sind.
Vereinfachtes Beispiel: Z.B. gibt es eine Checked Exceptions bei FileHandle.close(...) [heisst in der Klassenbibliothek nicht Filehandle, aber das ist vielleicht verständlicher]. Aber wie soll der Programmierer reagieren, wenn der code, den FileHandle nicht schliessen kann? Höchstens vielleicht noch 10 mal versuchen, aber das hilft in aller Regel auch nicht.
Brian Götz, einer der Mitentwickler der Sprache, sagt heute, dass die damals eigentlich nicht wussten, was sie taten.

Mehr code für Error-Handling heisst nicht unbedingt besseres Error-Handling. Das Gegenteil ist viel häufiger der Fall.

flaite:
Refactoring im Flaite Stil:

Du erzeugst eine Hierarchie für deine ErrorLogger


--- Code: ---Public Class SimpleErrorHandler
...
   Public Sub logError(Errorstring)
       Print "lsCl_Global:logError VLogToMedium Type noch nicht definiert"
   End Sub
...
End Class

Public Class SimpleErrorHandler

   Public Sub logError(Errorstring)
       Print "lsCl_Global:logError VLogToMedium Type noch nicht definiert"
   End Sub
End Class

Class DialogFullErrorHandler as SimpleError
  Public Sub logError(Errorstring)
       ' Code in logToDialogFull(ErrorString) hier rein copy&pasten
   End Sub

End Class

--- Ende Code ---
analog mit Log to central db, etc. verfahren.

Den verwendeten Errorhandler initialisierst Du im Konstruktor von MailMonitor

--- Code: ---Class MailMonitor
 Dim errorHandler as SimpleErrorHandler ' favour composition over inheritance (try google)
 Dim unid as String

   Public Sub New(vErrorHandler As ErrorHandler, String vUnid)
      errorHandler = vErrorHandler
      unid = vUnid  ' reicht aus als "reasonable minimal initial state"
   end sub     

   Public Sub doStuff()
      onError goto ErrorHandler
      Dim doc as Document
      doc = db.getDocumentByUnid(unid)
     
      exit sub
      ErrorHandler:
      me.errorHandler("Fehler in Methode doStuff von Klasse".... 
   end doStuff


--- Ende Code ---

So die Richtung. Dein ErrorHandler wäre in einer spezialisierten Klasse, die per Komposition in deinen sonstigen Code eingefügt wird. Sehr vermutlich machst Du das besser mit einfachen Subroutinen und verzichtest auf Klassen.

Wie gesagt: Möglicherweise überschätzt Du die Macht von OO und nutzt sie so, dass Du dir selbst in den Fuß schiesst.

khing:
So, jetzt bin ich völlig vom LS verwirrt  :-\
Baue ich in der Sub New keinen "On Error Goto ..." ein, dann wird der Fehler an den aufrufenden Agenten zurückgegeben und die Klasse wird wie erwartet zerstört. Soweit logisch...
Baue ich aber nur ein "On Error Goto Ende" ein (wobei Ende einfach Exit Sub beinhaltet), dann führt der Fehler nicht zur Zerstörung der Klasse... Das ist doch nicht normal oder??? Da ist doch kein Resume vorhanden und somit darf der Fehler doch nicht gehandelt sein?!?!?!  ??? ??? ???

@flaite: Danke für die vielen Infos und natürlich hast du recht mit den Grundlagen. Auf meinen unteren Ebenen habe ich das auch so umgesetzt, nur wollte ich aus "Bequemlichkeit" mit einmal die gesamten Mutter-Klassen und Funktionen zur Verfügung haben. Sicherlich muss ich mein Klassenmodell noch einmal überdenken....

Tode:
Auszug aus der Hilfe:
--- Zitat ---GoTo  label

Specifies that when the error occurs, execution continues with an error-handling routine that begins at label. The error is considered handled.
--- Ende Zitat ---

Das heisst: Deine ErrorRoutine muss ENTWEDER den Error erneut werfen, das sieht dann so aus:


--- Code: ---ErrorHandler:
    Error Error, err
--- Ende Code ---

ODER einen "anderen" error provozieren, indem Du ihn eben nicht handelst:

--- Code: ---ErrorHandler:
End Sub
--- Ende Code ---

Im zweiten Fall bekommst Du allerdings in der aufrufenden Sub / Function den Error "No Resume" und nicht den ursprünglich aufgetretenen Fehler, den musst Du Dir schon vorher merken...

ErrorHandling ist eine sehr komplexe Sache, wenn man es richtig machen will. In unserer eigenen ErrorHandling- Routine steckt mindestens eine Mannwoche an Arbeit / Finetuning von zwei erfahrenen Notes- Entwicklern... Wir haben aber auch Stacktraces, konfigurierbares Handling (Error Message an/aus (minimal oder ausführlich), Errormail an/aus, Reporting in Dokument an/aus, und auch Besonderheiten wie "NotesUIDocument.Refresh" triggert "QueryRecalc", beide sind aber in einem völlig anderen Script- Kontext, und damit geht der Stacktrace kaputt)...

khing:
Vielen Dank Torsten, genau das ist es.  :D So ein ähnliches Errorhandling habe ich auch gebaut.
Den Fehler noch einmal zu werfen hat mir die Klasse ganz schön hart unter den Händen weggezogen aber wenn ich einen eigenen Fehler werfe, dann gibt er es schön sauber an den Agenten zurück und führt auch das Delete aus. Das werde ich noch überall einbauen müssen ...  :o

Bugfreie Restwoche euch allen  ;)

Navigation

[0] Themen-Index

[*] Vorherige Sete