Best Practices: Error Handling in Lotus Script: Einleitung

[cpo]

Puh, da hab ich wieder viel gelernt...

Bei uns gibt' für Errorhandling die Regeln
a) jede Function hat einen Namen (variable am Anfang gesetzt)
b) jede scriptLib hat einen Namen (im Initialize)
c) jede Funktion gibt True oder False zurück und bekommt einen String für einen eventuellen Errortext mitgegeben
d) die texte des errors werden bei "erwarteten" Fehlern in freundlicher Sprache formuliert, bei unerwarteten macht das eine errorfunktion die Name der Funktion, der lib, des fehlers und zeilennummer zurückgibt
e) Aufruf der letzten Funktion immer im Errorhandler mit onerrorgoto ebendiesem -> daraus folgt, dass jede Funktion oben den goto und unten den errorhandler hat
f) Messageboxen etc. werden immer von der ersten, aufrufenden Funktion ausgegeben. Alles darunter gibt nur False und den Errortext zurück

Das klappt eigentlich ganz gut. Ist auf jeden Fall relativ stringent und einfach zu pflegen.
Das setzt allerdings voraus, dass man unter "Fehler" auch versteht, dass man abbrechen will/muß bzw. seine Funktionen so klein baut, dass man in der aufrufenden die Frage Abbruch oder nicht entscheiden kann.

CPO

[Semeaphoros]

Das ist auch ein interessanter und guter Ansatz, und zeugt von Bewusstsein des Problemes.

Vielleicht erzählen uns noch andere über die angewendete Error-Handling-Strategie?

[TMC]

Hier noch der Hinweis zu einem anderen Projekt, wo die Ergebnisse von hier einfließen sollten:
Script Library

TMC

[TMC]

Mich würde es mal konkret interessieren, wie man das bei einer Funktion wie folgender handhaben würde:

Code

Function PurgingArray(strSourceArray As Variant  ) As Variant
%REM
##########################################################################
# ID:                   0001
# Creator:             TMC (atnotes@gmx.de) 
# Categories:          Array-Handling
# Version:             0.1
# Date:                23. Nov. 2003
# Goal:                  Array alphabetisch sortieren und Leerzeilen entfernen
# Description:         
#                        
# Remarks:            
#                        
# Used Functions:   keine
# Call:                  z.B. über "PurgingList(doc.IchBinDasFeld)"
# Tested:               Action-Button in Maske
##########################################################################
%END REM 
   
   Dim k As Integer
   Dim i As Integer
   Dim j As Integer
   Dim h As Integer
   Dim r As Integer
   Dim memberArray() As String
   Dim temp As String
      
   'Erstelle Array aus Werten zum sortieren   
   For k = 0 To Ubound(strSourceArray)
      Redim Preserve memberArray(1 To k+1)
      memberArray(k+1) = Cstr(strSourceArray(k))
   Next
   
   'Set up für den Sortier-Algorithmus
   h = 1
   Do While h < k
      h = (h*3)+1
   Loop
   h = (h-1)/3
   If h > 3 Then
      h = (h-1)/3
   End If
   
   'Sorier-Algorithmus
   Do While h > 0
      For i = 1+h To k
         temp = memberArray(i)
         j = i-h
         Do While j >0
            If memberArray(j)>temp Then
               memberArray(j+h) = memberArray(j)
               memberArray(j) = temp
            Else
               Exit Do
            End If
            j = j-h
         Loop
      Next i
      h = (h-1)/3
   Loop
   
   'Ergebnis
   PurgingArray = memberArray
   
End Function

Die Funktion soll z.B. in einem Agenten laufen, der mehrere Dok-Felder in einer Collection abarbeitet, oder aber in einem Action-Button in einem Dokument, welches gerade im Bearbeitungsmodus geöffnet wird.

Was kann z.B. schiefgehen:
übergebender Feldinhalt ist kein String, sondern Nummer etc.
Könnte man ja über "If Not Datatype(strSourceArray) = 8 Then" abfragen.

Wie würde man denn als Rückgabewert der Funktion ein True / False einbauen und Fehlertext im False-Fall?


TMC

[eknori]

@TMC:

jetzt habt ihr schon so schön alles ausbaldovert; nur , der Name deiner Funktion und deren Beschreibung stimmen nicht überein. ( da steht nur was von Purge; ich erwarte daher kein Sort )

da du hier nicht das übliche true oder false ausgeben kannst sondern ein sortiertes, bereinigtes Array erwartest, muß die Fehlerbehandlung schon VOR dem eigentlichen Funktionsaufruf erfolgen. Es dürfen also nur gültige Werte an die func übergeben werden. Ansonsten darf die func gar nicht erst aufgerufen werden.

du meinst bestimmt ein C++ Konstruct, welches als function call den retVal als pointer auf einen wie auch immer gearteten Wert zurückliefert; die Funktion liefer aber ein klares true/false.

also etwa so

function SortAndTrim( varIn as Variant, *varOut as Variant ) as boolean

Ulrich

[koehlerbv]

Wie würde man denn als Rückgabewert der Funktion ein True / False einbauen und Fehlertext im False-Fall?

Was passiert denn eigentlich überhaupt in einer Functio nwie Deiner ? Du übergibst an die Function ein Array (oder auch nicht ;-) und bekommst das sortierte zurück. Aber auch das übergebene Array ist sortiert, sofern es sich um eine von Dir deklarierte Variable handelt. Das Ganze ist also unter Umständen "doppelt gemoppelt", was man sich durchaus zu Nutze machen kann:

Dim vMyArray as Variant
Dim szErrorMessage as String

vMyArray = ... (zu belegen)
szErrorMessage = ""

If SortArray (vMyArray, szErrorMessage) = True then
.......
End If

Du übergibst also vMyArray "by reference" (der Standard), und wenn Du das in der Function konsequent weiter bearbeitest, ist danach vMyArray sortiert. Fehlerfälle führen dazu, dass SortArray False zurück gibt, und in szErrorMessage kann man optional auch Fehlermeldungen an die aufrufende Routine übermitteln. Dann kann man sogar solche Fälle abfangen, dass die Routine wohl True zurück gibt, aber lt. szErrorMessage noch etwas zu beachten ist.

Das Ganze nur als ein Beispiel und eine Prinzip-Erklärung, was man alles so machen kann. Als ein weiteres Beispiel kann man das o.g. auch "umdrehen":

Function SortArray (iResult as Integer) as Variant

Jetzt gibt SortArray ein sortiertes Array zurück, ob die Routine erfolgreich war, steht aber jetzt in iResult.

Wie gestern schon mal geschrieben: Verteil' doch off-list an die aktiven Teilnehmer des Threads einfach mal Routinen, und dann schauen wir uns erstmal an, wie jeder das so anstellt und haben eine gemeinsame Diskussionsgrundlage. Danach gehen wir wieder on-list ;-)

Ciao,
Bernhard

[Semeaphoros]

Ulrich, da bin ich aber nicht ganz einverstanden.

Ja, der Name der Funktion ist ungeschickt gewählt, aber das beantwortet die Frage von TMC ja nicht.

Hingegen Deine Aussage, die Ueberprüfung sollte ausserhalb der Funktion stattfinden, kann ich nun plattweg nicht akzeptieren. Machst Du die Ueberprüfung vor dem Aufruf, kannst Du auch gleich die ganze Funktion ausserhalb ausprogrammieren, denn genau dadurch geht ein grosser Teil der Rationalisierung verloren.

Es gibt da eine ganez Reihe von Möglichkeiten, das Problem zu lösen. Die in C üblriche Variante, die Du da schilderst, ist durchaus eine Möglichkeit, geht hier aber nicht, da LS keine Pointer unterstützt.

Möglich wäre, im Fehlerfall ein Nothing oder ein Null zurückzugeben, hat allerdings den Nachteil, dass dann der Grund des Problemes nicht mitgeteilt werden kann.

Weitere Möglichkeiten bestehen darin, mit der Funktion eben doch True oder False zurückzugeben und das Resultat selber als weiterer Parameter übergeben wird oder sogar den Originalparameter überschreibt. Da gelten allerdings Einschränkungen in LS.

Ebenso wäre es möglich, statt eines einfachen Standard-Rückgabewertes eine selbstdefinierte Datenstruktur zurückzugeben. Das ähnelt dann schon sehr dem in C üblichen Verfahren, ist aber mehr nach dem Geschmack irgendwelcher Pascal-Programmierer. Auch hier gilt, diese Datenstruktur kann entweder als Rückgabewert der Funktion geliefert werden oder aber auch in der Parameterliste stehen. Auch hier ist leider in LS nicht ganz alles möglich, was man sich wünschen könnte.

Ganz andere Möglichkeiten würden allerdings bestehen, wenn man die ganze Sache gleich in ein entsprechendes Objekt einpacken würde, dann hätte man auch ganz andere Möglichkeiten, wie zum Bleistift das Hinterlegen der Fehlerbeschreibung in einem Property des Objektes.

Grundsätzlich bleibe ich dabei: das Error-Handling gehört hier ganz klar in die Funktion und die Funktion handelt unverantwrotlich, wenn sie verlangt, dass die ihr übergebenen Parameter in jedem Falle gültig sind. Genau damit hat zwar 16-Bit Windows viel Performance hingezaubert, ist aber im Grunde genommen auf die Nase gefallen.

[TMC]

danke für das Feedback; ich bin auch der Meinung dass Errorhandling - soweit möglich - 'idiotensicher' in die Function sollte.

Zum Thema Namensgebung der geposteten Funktion:
Ist in der Tat irreführend, kommt daher dass ich diese Function noch erweitern wollte um ein Unique, und davon wieder weggekommen bin (weil Auslagern in separate Function) und hatte den Namen noch nicht geändert...... War aber auch nicht für die Frage relevant.....

TMC

[TMC]

Ich grabe mal diesen etwas älteren Thread wieder aus.

Und da gleich eine Frage:

Angenommen ich habe einen Script-Abschnitt, wo ich erwarte, dass ein Error 91 auftreten kann.

Hier möchte ich diesen dann anders händeln als Global.

Also: Im Script selbst will ich z.B., wenn Error 91 auftritt, zu "errHandler" springen. Aber in einem bestimmten Codeabschnitt will ich - wenn der Error 91 auftritt, wo anders hinspringen.

Beispiel:

Code

On Error goto errHandler
Code Code Code Code Code Code 
Code Code Code Code Code Code 
'---> Start: Hier möchte ich Error 91 speziell abfangen
Code Code Code Code Code Code 
Code Code Code Code Code Code 
'<---- Ende
Code Code Code Code Code Code 
Code Code Code Code Code Code 
Code Code Code Code Code Code 

exitScript:
   Exit Sub


errHandler:
  Select Case Err
  Case 91
      Resume Sprung1
  Case Else
      Msgbox "Es ist ein Fehler aufgetreten." & Chr(10)  & Chr(10) _
      & "Fehlermeldung: " & Error$ & Chr(10) _
      & "Fehlernummer: " & Err & Chr(10) _
      & "Codezeile: " & Erl & Chr(10) _
      ,64,"Error"
      Resume exitScript
  End Select

Wie würde man sowas umsetzen?

Matthias

[animate]

einfach vor deinen speziellen Codeabschnitt ne andere Sprungmarke spezifizieren (also On Error Goto Hell) und nach dem Abschnitt wieder die normale (On Error Goto errHandler)

[animate]

Gute Artikel zu dem Thema gibts übrigens hier:

http://www-10.lotus.com/ldd/today.nsf/a2535b4ba6b4d13f85256c59006bd67d/a55740873b33ca2585256d4e005d2586?OpenDocument
http://www-10.lotus.com/ldd/today.nsf/62f62847467a8f78052568a80055b380/a2b75e1747c115c285256d6e00602957?OpenDocument

[TMC]

Thomas, würde das so ungefähr dann klappen?

Code

On Error goto errHandler
Code Code Code Code Code Code
Code Code Code Code Code Code
On Error goto Hell
Code Code Code Code Code Code
Code Code Code Code Code Code
On Error goto errHandler
Code Code Code Code Code Code
Code Code Code Code Code Code
Code Code Code Code Code Code

exitScript:
  Exit Sub

Hell:
praytogod
Exit Sub

errHandler:
  Select Case Err
  Case 91
      Resume Sprung1
  Case Else
      Msgbox "Es ist ein Fehler aufgetreten." & Chr(10)  & Chr(10) _
      & "Fehlermeldung: " & Error$ & Chr(10) _
      & "Fehlernummer: " & Err & Chr(10) _
      & "Codezeile: " & Erl & Chr(10) _
      ,64,"Error"
      Resume exitScript
  End Select

Also Error nimmt so temoprär die neue Sprungmarke Hell an, und man stellt das einfach dann wieder zurück?

 

Matthias

[Semeaphoros]

Ja, oder noch komfortabler mit "On Error 91 Goto Hell"

[TMC]

OK, prima, danke für die Tipps.

Hoffe die Hölle nimmt meine Gebete in der Sprungmarke wahr  

[Semeaphoros]

Aehm, dann würde ich Dir empfehlen, den Error mit

Error 91

zu provozieren ...

[TMC]

Ich habe mir jetzt mal eine eigene Display-Error - Sub erstellt, die ich Euch nicht vorenthalten will.
Insbesondere hat mich Getthreadinfo interessiert.

Wie Andreas schon angemerkt hat, weicht LSI_THREAD_LINE ab von der tatsächlichen Zeilennummer des Fehlers. Ich habe festgestellt, dass Leerzeilen nicht mitgezählt werden.
Da wir aber in Script eh "Erl" zur Verfügung haben, brauche ich das auch nicht.

Code

Sub DisplayError

   Dim strTitle As String
   Dim strMsg As String
   Dim vProcedure As Variant

   vProcedure = Getthreadinfo( LSI_THREAD_CALLPROC )

   strTitle = "An error occured"

   strMsg = _
   "Error: " & Err & " - " & Error$ & Chr(10) & Chr(10)_
   & "Procedure: " & vProcedure & Chr(10)  & Chr(10)    _
   & "Line: " & Erl & Chr(10)

   Msgbox strMsg , 48, strTitle

End Sub

Gedacht ist die Sub für die ScriptLibrary.
Wichtig: in die Options der ScriptLib muss die Zeile

Code

%INCLUDE "lsconst.lss" 

, damit Getthreadinfo funktioniert.

So funktioniert das ganze fein. Ich habe mal in mehreren Functions im Errorhandler die Zeile "Call DisplayError" eingefügt, und es wird sauber der Function-Name angezeigt.

Matthias

[TMC]

Hier noch ein Thread zum Thema: "Wie gebe ich meiner Function als Integer mit, wie denn diese eigentlich gelaufen ist"

http://www.atnotes.de/index.php?board=7;action=display;threadid=16062

[sja]

Hallo @all,

das Thema ist für mich unheimlich aktuell. Ich versuche verzweifelt eine Lösung für einen Agent, der schon in der Produktion läuft, zu finden.

Der Agent habe ich schon in
http://www.atnotes.de/index.php?board=3;action=display;threadid=16004
gepostet.

Ihr habt mir damals schon mit dem Agent sehr geholfen. Für weitere Hilfe werde ich unheimlich dankbar.

Das Problem:
wenn es nur eine einzige Adresse gibt und zwar im Adressbuch nicht vorhanden, dann kommt Fehlermeldung, "AMgr: Agent ('LastUpdateMail' in "db.nsf') error message: Unable to send mail, no match found in Name & Address Book(s)", und Ausführung des Agent's wird unterbrochen. Ich habe versucht das Problem mit

On Error Resume Next

zu lösen. Ich habe so verstanden, dass in diesem Fall das Script soll weiter laufen, aber es wird wieder nach der Fehlermeldung unterbrochen.


Function MailSenden()
   Projekt = PymDoc.GetItemValue("KundenProjektTitel")(0)
   Kunde= PymDoc.GetItemValue("KundenName")(0)
   Betreff = "..."
   Message = "..."
   VB = PymDoc.VFVB(0)
   SE = PymDoc.VFSE(0)
   VL = PymDoc.VFVL(0)
   TL = PymDoc.VFTL(0)
   
   If status = "Presales" Then
...
...
...   
   Else       
   
   '*** 21 ***         
      If nTagen = "21" Then
         Prior = "1"
         an(1) = SE
         kopie(1) = VB
         kopie(2) = TL               
   '*** 28 ***         
      Elseif nTagen = "28" Then
         Prior = "1"
         an(1) = SE
         an(2) = TL
         kopie(1) = VB
   '*** 35 ***         
      Elseif nTagen = "35" Then
         Prior = "1"
         an(1) = VB
         an(2) = SE
         an(3) = TL
         kopie(1) = VL   
   '*** 42 ***         
      Elseif nTagen = "42" Then
         Prior = "1"
         an(1) = VB
         an(2) = SE
         an(3) = VL
         an(4) = TL
      End If
   '***************************************************   
   End If
   ftarrayAn = Fulltrim(an)
   ftarrayKopie = Fulltrim(kopie)
   
   If Not ((ftarrayAn(1) = "") And (ftarrayKopie(1) = "")) Then
      Set MailDoc = New NotesDocument(db)
      MailDoc.Form = "Memo"
      MailDoc.Subject = Betreff
      MailDoc.SendTo = an
      MailDoc.CopyTo = kopie
      Set rtitem = New NotesRichTextItem( MailDoc , "Body" )
      Call rtitem.AppendText( Message)      
      Call rtitem.AppendDocLink( PymDoc, Projekt)
      Call rtitem.AddNewLine( 2 )
      Call rtitem.AppendText( "Vielen Dank")
      MailDoc.Importance = Prior         
      MailDoc.Send(False)

      On Error Resume Next
      
   End If
   
   Erase an
   Erase kopie
   
End Function


Vielen Dank im Voraus
Sofia

[Glombi]

Das
 On Error Resume Next

muss als erstes im Code stehen, denn sonst wirkt es erst ab da, wo es im Code vorkommt.

Generell ist  On Error Resume Next mit Vorsicht zu genießen, da es mitunter gefährlich ist, einen Fehler zu ignorieren.
In Deinem Fall würde ich das
 On Error Resume Next
vor dem
          MailDoc.Send(False)
schreiben.

Andreas
 

[koehlerbv]

... und danach muss wieder auf die "normale" Fehlerroutine umgeschaltet werden.
Man kann es aber auch ganz anders machen und auf On Error Resume Next ganz verzichten, indem man im normalen ErrorHandler die beiden Fehlernummern 4294 und 4295 abfragt (niemand gefunden bzw. doppelte Entsprechung). Ist Err = 4294 Or Err = 4295 dann folgt ein Resume Next, sonst wird der bisherige ErrorHandler weiter abgearbeitet.

Die ganze Sache ist aber sowieso mit Vorsicht zu geniessen, da docMail.Send an niemanden sendet, wenn nur bei einem der Fehler 4294 bzw. 4295 auftritt.

HTH,
Bernhard