Ein "delete me" funktioniert soweit ich weiß nicht, was aber geht ist
dim this
set this = me
delete this
Meiner Meinung nach ist das aber auch keine optimale Lösung, ich denke dass dein ErrorHandler nicht korrekt ist. Wenn die Klasse nicht richtig initialisiert werden konnte, dann darf halt nicht weiter gemacht werden.
LG Roland
Ja, da liegt anscheinend mein Problem. Ich hatte schon die ganze Zeit so meine Vermutung, dass der nicht richtig arbeitet.
Ich habe eine eigene ErrorHandler-Klasse, die an die aktuellen Klasse "MailMonitor" vererbt wird. In der Klasse MailMonitor habe ich die Sub "logError" der ErrorHandler-Klasse überschrieben (damit ich ein Errorlogging im MailMonitor noch schreiben kann) und erst zum Ende rufe ich "Call Basis..logError(Errorstring)" auf.
Also vereinfacht so:
Public Class ErrorHandler
...
Public Sub logError(Errorstring)
'Verarbeitet hier grundlegende Fehler
End Sub
...
End Class
Public Class Basis As ErrorHandler
...
End Class
Public Class MailMonitor As Basis
Private Sub logError(ErrorString)
'Schreibe Infos für MailMonitor weg
...
'Aufruf der Sub aus Mutterklasse
Call Basis..logError(Errorstring)
End Sub
End Class
Kann das daran liegen? Es geht auch Call Errorhandler..logError(Errorstring) und da bin ich mir nicht sicher :-\
Sorry, das habe ich natürlich vergessen Bernhard. Sonst funktioniert diese Klasse/Sub ganz normal - also stopt die aktuellen Ausführungen.
Public Sub logError(ErrorString)
On Error GoTo errHandler
Dim i As Integer
Dim max As Integer
Dim vCurrChar As String*1
max = Len(Me.vLogToMedium)
Call Me.InitErrorFullOutput()
For i=0 To max-1
vCurrChar = Mid(Me.LogToMedium, i+1 ,1)
Select Case (vCurrChar)
Case CStr(ErrorHandler_LogTo_CentralLogDB): LogTo_CentralLogDB(ErrorString)
Case CStr(ErrorHandler_LogTo_DialogFull): logToDialogFull(ErrorString)
Case CStr(ErrorHandler_LogTo_DialogSimple): logToDialogSimple(Errorstring)
Case CStr(ErrorHandler_LogTo_StatusBar): logToStatusBar(Errorstring)
Case Else: Print "lsCl_Global:logError VLogToMedium Type noch nicht definiert"
End Select
Next
Ende:
Exit Sub
errHandler:
Me.logToDialogSimple("Library: lsCL_Global -- Sub: logError -- Returntype: -- Sub/Function: " & CrLF & vInitErrorFullOutput)
Resume Ende
End Sub
In LogTo_CentralLogDB(ErrorString) wird der Fehler einfach an eine Funktion weitergegeben, die die Fehler in eine zentrale Db schriebt (das passiert auch im o. g. Fall). logToDialogSimple(Errorstring)gibt zum Beispiel nur eine MessageBox aus. Wie gesagt, funtkioniert das im Normalfall aber nur nicht, wenn ich die Sub logError überschreibe....
Refactoring im Flaite Stil:
Du erzeugst eine Hierarchie für deine ErrorLogger
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
Den verwendeten Errorhandler initialisierst Du im Konstruktor von MailMonitor
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
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.
Auszug aus der Hilfe:GoTo label
Specifies that when the error occurs, execution continues with an error-handling routine that begins at label. The error is considered handled.
Das heisst: Deine ErrorRoutine muss ENTWEDER den Error erneut werfen, das sieht dann so aus:
ErrorHandler:
Error Error, err
ODER einen "anderen" error provozieren, indem Du ihn eben nicht handelst:
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)...