Das Notes Forum

Best Practices => Diskussionen zu Best Practices => Thema gestartet von: Semeaphoros am 31.10.03 - 00:05:11



Titel: Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: Semeaphoros am 31.10.03 - 00:05:11
An verschiedenen Stellen haben wir unterdessen über das Error-Handling geschrieben und verschiedentlich versprochen, dass wir das zum selbständigen Thema erheben wollen. Ich möchte damit hier jetzt anfangen. Folgendes Vorgehen habe ich mir vorgestellt (wobei die Diskussion diesen Weg bestimmt erweitern wird):

Ich werde im nächsten Posting mal zuerst einen generellen Ueberblick über Runtime-Errors in LotusScript machen, in den dann folgenden Postings stelle ich dann die für das Error-Handling relevanten LotusScript Statements vorstellen. Daraufhin möchte ich die Diskussion in der Form eröffnen, dass einzelne von Euch ihre eigenen Taktiken für das Error-Handling vorstellen. Bernhard hat kürzlich schon mal ein ganz grobes Grundgerüst skizziert, wie man das angehen kann. Gleichzeitig werden dabei auch die Haken und Ecken des Error-Handlings auftauchen, und es wird hoffentlich an manchen Orten zum Ueberdenken des Error-Handling-Ansatzes führen, tatsächlich ist es eines der Gebiete, die mehr als verträglich vernachlässigt wird.

Also, gleich gehts los ......  :D


PS: Ich will auch endlich meinen eigenen Thread haben ....  ;D


Titel: Grundlagen des LotusScript Error-Handlings
Beitrag von: Semeaphoros am 31.10.03 - 00:19:18
Eigentlich gibt es in einer LS-Applikation 3 Sorten von Fehlern, die während der Laufzeit auftreten können:

1. Fehler, welche von LotusScript entdeckt und mit einer Fehlermeldung versehen werden. Wenn man gegen solche Fehler nichts unternimmt, bekommt der Benutzer eine Fehlermeldung und das Script bricht ab. Beispiel:

Code:
Resultat = Var1 / 0

erzeugt einen Fehler, weil die Division durch 0 nicht erlaubt ist.

2. Fehlerzustände, die LotusScript nicht eindeutig als solche erkennen kann, auf die das Programm dann entweder selber reagieren muss, oder es führt dann später im Code zu einer entsprechenden Fehlfunktion des Programmes, weil die Umstände nicht so waren wie erwartet. Beispiel:

Code:
Dim db As NotesDatabase
Call db.Open( "HongKong", "sales.nsf"

Wenn auf dem Server "HonKong" die Datenbank "sales.nsf" nicht existiert, passiert hier mal gar nichts. Erst wenn ich zum Beispiel mit db.GetDociumentById(..), erhalte ich die Fehlermeldung, dass die Datenbank nicht offen ist.

3. Dann gibt es natürlich auch noch die logischen Fehler. Das Programm läuft zwar korrekt ab, erzeugt weder Fehlermeldungen noch werden "illegale Zustände" wie unter 2. erzeugt, aber trotzdem ist das Ergebnis nicht das, was man erwartet. Entweder stimmt die Applikationslogik nicht, oder das Programm ist nicht nach den Spezifikationen umgesetzt worden. Natürlich können wir hier nicht über diese Probleme reden, da diese ganz individuell angegangen werden können. Was wir hier diskutieren können, sind Taktiken, die man anwenden kann, um diese Probleme einzugrenzen und zu lösen.


Titel: Fehlerbehandlung: Grundstrategien
Beitrag von: Semeaphoros am 31.10.03 - 00:35:22
Die oben aufgeführten einzelnen Fehlerkategorien erfordern natürlich unterschiedliche Ansätze, um sie zu "behandeln":

1. Von LotusScript erkannte und behandelte Fehler
Da in diesem Fall ein Abbruch des Programmes erfolgt, ist dies eigenlich für den Anwender eine Katastrophensituation, die man wenn immer möglich vermeiden sollte. LotusScript stellt dafür eine ganze Reihe von Statements zur Verfügung, die einem ermöglichen, die "Situation" zu retten. Im Vordergrund stett das On Error Statement. Diese Fehlerbehandlungs-Mechanismen werden in den nächsten Postings im einzelnen noch vorgestellt.

2. Fehlersituationen, die von LotusScript nicht mit einem "Fehler belohnt" werden
Hier gibt es verschiedene Strategien:
A Gar nichts machen und warten, bis irgendwann einmal später die Situation 1. eintrifft und ein Fehler generiert wird, der abgehandelt werden kann.
B In Abhängigkeit von der Situation versuchen, festzustellen, ob das Statement den gewünschten Erfolg gebracht hat. Im Fall von NotesDatabase.Open gibt es da verschiedene Varianten:
Diese Methode hat einen Rückgabewert: True, wenn die Datenbank geöffnet werden konnte, andernfalls False, wir können also den Rückgabewert auswerten:

Code:
Dim db As NotesDatabase
If Not db.Open( "HongKong", "sales.nsf" Then
   Messagebox "Die Datenbank konnte nicht geöffnet werden"
Else
   ........
End If
Alternativ kann die Eigenschaft IsOpen abgefragt werden:
Code:
Dim db As NotesDatabase
Call db.Open( "HongKong", "sales.nsf"
If Not db.IsOpen Then
   Messagebox "Die Datenbank konnte nicht geöffnet werden"
Else
   ........
End If


Die Designer-Hilfe ist dabei zu Rate zu ziehen, bei jedem Befehl, bei jeder Methode und Funktion ist jeweils angegeben, was passiert, wenn nicht das erwartete Resultat erreicht wird. Insbesondere ist zu beachten, dass es grundsätzlich keine Systematik vorhanden ist, wann Methode 1 mit der Fehlermeldung und wann Methode 2 über einen Status-Returnwert oder eine Status-Abfrage oder ähnliches zur Anwendung gelangen muss.


Titel: Die Error-Behandlungs-Befehle: On Error
Beitrag von: Semeaphoros am 31.10.03 - 01:20:09
Das On Error Statement verändert das Verhalten von LotusScript. Sobald dieses Statement ausgeführt wurde, wird keine Fehlermeldung generiert, sondern eine vom Programmierer definierte Aktion ausgeführt.

1. On Error ohne Fehlernummer
Diese Variante von On Error kann in 3 verschiedenen Formen erscheinen:

a. On Error Goto Sprungadresse
In diesem Falle wird der Code ausgeführt, der hinter der Sprungadresse (Label) aufgeführt wird. Dieser Code muss mit einer Form von Resume abgeschlossen werden, damit LotusScript weiss, dass der Fehler jetzt behandelt ist. (Das besagt nciht zwingend, dass der Fehler dadurch behoben oder beseitigt wurde!).
Beispiel:
Code:
Sub Demo
On Error Goto ErrHandler
 ...... hier steht der Programmcode, bei einem Fehler wird statt einer Fehlermeldung
        der unten aufgeführte Code ausgeführt
.....
Exit Sub
ErrHandler:
  Print "Es ist ein Fehler aufgetreten"   ' Hey, hier sollte sinnvoller Code stehen :-)
Resume

b. On Error Goto 0
Mit diesem Statement wird eine besondere Fehlerbehandlungsroutine wieder zurückgesetzt. Es hängt jetzt davon ab, ob meherere On Error-Statements definiert waren oder nicht. Dieses Statement setzt zurück auf den Zustand, der vor dem zuletzt ausgeführten On Error Statement existierte. Allenfalls wird dadurch wieder das LotusScript Standardverfahren hergestellt. Auch wenn On Error Goto 0 nicht verwendet wird, werden alle On Error-Statements deaktiviert, sobald man an das Ende eines Moduls (sub oder function oder Methode) erreicht hat und das Modul verlässt. Beispiel unter c.

c. On Error Resume Next
Eine der gefährlichsten Konstruktionen überhaupt, die Fehlermeldung wird ganz einfach unterdrückt und das Programm mit dem nächsten Statement fortgesetzt. Auf diesem Weg werden Fehler vom Typ 1. zu Fehlern vom Typ 2., die anschliessend eine Ueberprüfung des Zustandes erfordern.
Code:
Dim dir As NotesDbDirectory
Dim db As NotesDatabase
Set dir = s.GetDbDirectory("")
On Error Resume Next
Set db = dir.CreateDatabase("quack.nsf", True)
On Error Goto 0
If db is nothing then
   Messagebox "Datenbank existiert bereits"
End if

2. On Error mit Fehlernummer
Alle drei oben beschriebenen Varianten können mit einer Fehlernummer versehen werden. Während bei obigen Beispielen immer alle Fehlermeldungen unterdrückt und speziell behandelt werden, lässt sich mit Angabe einer Fehlernummer dieses Verfahren auf genau eine einzige Fehlermeldung beschränken. Beispiel:

Code:
Sub Demo
  On Error 11 goto DivByZero
  Resultat = Var1 / 0
  On Error Goto 0

Exit Sub

DivByZero:
   Messagebox "Division durch 0 aufgetreten"
   Resume Next
End Sub

Die Fehlernummern findet man in der Designerhilfe. Ausserdem kann man statt mit Nummern mit "sprechenden" Konstanten arbeiten, wenn man die folgenden Dateien mit HIlfe von %include in sein Programm integriert:

lsxbeerr.lss defines constants for errors raised by Domino Designer back-end methods.
lsxuierr.lss defines constants for errors raised by Domino Designer front-end (UI) methods.
lserr.lss defines constants for errors raised by LotusScript.
lsconst.lss defines constants for use as arguments in LotusScript statements and functions.


Titel: Die Error-Behandlungs-Befehle: Resume
Beitrag von: Semeaphoros am 31.10.03 - 01:30:23
Resume schliesst eine Fehlerbehandlungsroutine ab und teilt somit LotusScript mit, dass der Fehler nicht mehr als solcher zu betrachten ist (technisch gemeint natürlich)

Das Statement kann in 4 Formen auftreten:

Resume
Resume 0
Resume Next
Resume Sprungadresse

Resume und Resume 0 sind gleichbedeutend:
Mit diesen Befehlen wird das Statement, das den Fehler verurstachte, noch einmal ausgeführt: Achtung: das darf natürlich nur gemacht werden, wenn in der Fehlerbehandlungsroutine der Grund für den Fehler beseitigt wurde, also beispielsweise nach einem neuen Dateinamen gefragt wurde. Sonst passiert der Fehler ja gleich noch einmal und wir landen gleich wieder am selben Ort ....... und haben eine Endlosschleife ...... (Hinweis für TMC: Das wäre vielleicht als Beispiel in die Weihnachsschleifen-Sammlung aufzunehmen)

Mit Resume Next wird die Programmausführung beim nächsten Befehl hinter dem Statement, welches den Fehler auslöste, fortgesetzt. Auch hier gilt: im Fehlerbehandlungsprgramm sollte dafür gesorgt werden, dass das Programm weitergeführt werden kann. Hier ist es allerdings nicht so tragisch wie oben, das Programm wird ja einen Schritt nach der Fehlerstelle weitergeführt. Also auch wenn ein weiterer Fehler auftritt und die Routine wieder aufgerufen wird, kommen wir trotzdem im Programmablauf vorwärts. Vorsicht ist natürlich angebracht.

Resume Sprungadresse
Hier können wir das Programm an einem beliebigen Label fortsetzen, damit Teile, die sonst durch den Fehler nicht laufen würden, überspringen.
Beispiel:
Code:
Sub Demo
  On Error Goto ErrHandler
  ... hier der Code
AfterError:
  Print "Routine Demo beendet"
Exit Sub

ErrHandler:
   Print "Es ist ein Fehler aufgetreten"
   Resume AfterError:
End Sub



Titel: Funktionen innerhalb des Error-Handlings
Beitrag von: Semeaphoros am 31.10.03 - 01:41:38
Da wir ja jetzt mit On Error die Fehlermeldungen unterdrücken können, müssen wir in unserer Fehlerbehandlungsroutine feststellen können, was denn nun passiert ist. Dafür stehen uns 3 Funktionen zur Verfügung:

Err gibt uns die Fehlernummer an.
Errl gibt uns die Zeilennummer des Fehlers an (Achtung, funktioniert nur richtig, wenn der Fehler nicht in einer aufgerufenen selbst definierten Funktion oder Subroutine auftritt)
Error$ gibt uns den Text der Standard-Fehlermeldung  an.

Beispiel:
Code:
Sub Demo
  On Error Goto ErrHandler
  ... hier der Code
AfterError:
  Print "Routine Demo beendet"
Exit Sub

ErrHandler:
  Print "Der Fehler mit Nummer " &  Str(Err) & " mit der Meldung " & Error$ & " ist bei Zeile " & Str(Errl) & " aufgetreten. Wir steigen aus"
  Resume AfterError:
End Sub


Titel: Error Statement: Ausnutzung des Systems für unsere Zwecke
Beitrag von: Semeaphoros am 31.10.03 - 01:47:53
Da gibt es jetzt zu allem noch die Möglichkeit, dass wir als Trittbrettfahrer auf das System aufspringen können: Mit dem Error-Statement können wir selber eigene Fehlernummern und Fehlermeldungen generieren:

Error 100

löst die Fehlerbehandlung mit Nummer 100 aus

Error 101,"Dies ist unser eigener Fehler"

macht dasselbe, erzeugt aber zusätzlich noch den Fehlertext "Dies ist unser eigener Fehler"

Mit Hilfe des Error-Statements lassen sich an beliebiger Stelle im Programm entweder eigene Fehler "produzieren" oder alle LotusScript Fehler simulieren (praktisch, wenn man nicht das richtige Umfeld zur Verfügung hat).

Beispiel:
Code:
Public x As Single
Const TOO_SMALL = 1001, TOO_BIG = 1002
Sub GetNum
   Dim Num As String
   On Error GoTo Errhandle
   Num$= InputBox$("Enter a value between 1 and 100:")
   x! = CSng(Num$)     ' Convert the string to a 4-byte single.
   ' Check the validity of the entry.
   If x! < 1 Then
      Error TOO_SMALL, "The number is too small or negative."
   ElseIf x! > 100 Then
      Error TOO_BIG, "The number is too big."
   End If
   ' If the script gets here, the user made a valid entry.
   MessageBox "Good job! " & Num$ & " is a valid entry."
   Exit Sub
   ' The user did not make a valid entry.
   ' Display the error number and error message.
Errhandle:    
   ' Use the Err function to return the error number and
   ' the Error$ function to return the error message.
   MessageBox "Error" & Str(Err) & ": " & Error$
   Exit Sub
End Sub


Titel: Bitte ergänzen und fortfahren
Beitrag von: Semeaphoros am 31.10.03 - 01:51:02
Ich habe glaube ich ziemlich vollständig abgedeckt, was an Theorie zur Fehlerbehandlung gehört. Garantieren tue ich das natürlcih nicht  ;D da aber andere Leute schon ihre zusätzlichen Beiträge versprochen haben, werden allfällige Lücken sicher rasch gefüllt.

Es gibt verschiedene Taktiken, mit den oben aufgeführten Mitteln funktionierende Fehlerbehandlungen zu erstellen. Jeder hat da gewisse Vorlieben. Gerne würde ich jetzt von Euch Beispiele sehen, wie Ihr das macht und wir können dann gemeinsam Vor- und Nachteile der einzelnen Taktiken diskutieren. Das wird bestimmt sehr spannend.

Jens


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: animate am 31.10.03 - 08:34:06
Ich habe einen Tipp hinzuzufügen:

mit der LS-Funktion GetThreadInfo kann man sich Informationen besorgen, die man sehr gut in einem Errorhandler gebrauchen kann (z. B. den Namen der Funktion in der der Fehler auftritt oder gleich den ganzen call stack)

Bei dem Beispiel
Zitat
Sub Demo
  On Error 11 goto DivByZero
  Resultat = Var1 / 0
  On Error Goto 0

Exit Sub

würde ich mit gutem Beispiel voran gehen und anstelle der 11 die entsprechende Konstante ErrDivisionByZero (definiert in lserr.lss) verwenden, also

Zitat
Sub Demo
  On Error ErrDivisionByZero goto DivByZero
  Resultat = Var1 / 0
  On Error Goto 0

Exit Sub
(ein persönlicher Kampf gegen nichtssagende Zahlenkonstanten)


Titel: GetThreadInfo
Beitrag von: Semeaphoros am 31.10.03 - 08:53:19
Danke

Diese Funktion ist wirklich sehr hilfreich, nicht nur beim ErrorHandling, im Gegensatz zu den obigen Statements, die alle dem ANSI-Standard folgen, ist GetThreadInfo nur LotusScript und darüber hinaus auch noch Plattformabhängig (besonders wichtig bei Script, welches auf dem Server läuft).

Auch der Hinweis auf die Konstanten ist richtig, das steht eigentlich gerade unterhalb des Beispiels, das Du zitierst, Dein Beispiel wäre dort oben wirklich hilfreich gewesen :-)

Hier noch der Auszug aus der Hilfe zu GetThreadInfo:

Returns system information about the thread.

Syntax

GetThreadInfo (Dim InfoID  as Integer)

Elements

InfoID

Information to be returned

Return values

Data

A variant containing the information to be returned.

Usage

Pass any of the LSI_ constants from the table below to GetThreadInfo to have it return the current value of that constant.

LSI_THREAD_LINE   Current Line Number
LSI_THREAD_PROC   Name of current procedure
LSI_THREAD_MODULE   Name of current module
LSI_THREAD_VERSION   LotusScript version number
LSI_THREAD_LANGUAGE   (Human) language setting
LSI_THREAD_COUNTRY   Country or region setting
LSI_THREAD_TICKS   Get current clock ticks
LSI_THREAD_TICKS_PER_SEC   Get clock ticks per second (supported only on platforms that support parallel processing primitives)
LSI_THREAD_PROCESS_ID   Get current process ID (supported only on platforms that support parallel processing primitives)
LSI_THREAD_TASK_ID   Get current task ID (supported only on platforms that support parallel processing primitives)
LSI_THREAD_CALLPROC   Get the name of the calling procedure
LSI_THREAD_CALLMOD   Get the name of the calling module
The values of the constants are defined in LSPRVAL.LSS, which is automatically included through LSCONST.LSS.


Titel: Re: Getthreadinfo
Beitrag von: Glombi am 31.10.03 - 09:13:34
Ich habe mal folgendes ausprobiert:

ErrorHandling:
   
Dim cproc As Variant
Dim cmod As Variant
Dim cline As Variant

cproc = Getthreadinfo( LSI_THREAD_CALLPROC )
cmod = Getthreadinfo( LSI_THREAD_CALLMODULE )   
cline = Getthreadinfo( LSI_THREAD_LINE )

cmod liefert mir aber leider nur wohl nur die Notes-interner ID des Modules, nicht den Namen des Moduls, in dem der Fehler auftrat.
cline liefert eine andere Zahl als Erl.

Ich kann mich dunkel erinnern, dass LSI_THREAD_CALLMODULE  schon mal den Namen der Sub ausgegeben hat (evtl. liegt es an meiner Versio 5.0.9)

Andreas


Titel: On Error - wo definieren
Beitrag von: Glombi am 31.10.03 - 09:17:03
Wenn man ein On Error... verwendet, sollte man sich ebenfalls überlegen, wo man das überall macht:
- in jeder Sub / Function ?
- nur in der Main Sub (Initialize, Click,...)
- Was ist bei Verwendung von Script Libraries, wenn dort ein Fehler auftritt?

Ich habe den Fall gehabt, dass ich in einer Sub das On Error goto ...hatte, das Script aber bei Auftreten eines Fehler die Sprungmarke aus der aufrufenden Sub, wo auch On Error goto... stand, verwendet hatte.

Wenn in einer Unterfunktion ein Fehler auftritt, so muß man das in der Hauptfunktion berücksichtigen! Man kann zwar in der Unterfunktion wunderbar eine Fehlermeldung ausgeben, in der Hauptfunktion geht es dann aber munter weiter...
Daher kann es sinnvoll sein, alle Unterfunktionen als Function zu definieren, die dann True oder False zurückgeben. Oder man verwendet ein Parameter (Call by reference), denn man dann auf True oder False setzt, und dann in der aufrufenden Sub abfragt.



Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: animate am 31.10.03 - 09:21:42
Mir fällt gerade noch was ein: es kann auch sehr vorteilhaft sein, wenn man Fehler, die auftreten, loggt. Dazu bietet LS eine sehr schöne Klasse an: NotesLog.

Gleichzeitig habe ich noch eine Frage, die mich zur Zeit beschäftigt: Die für mich wichtigsten Informationen zu einem Fehler neben seinem Namen sind Zeilennummer und Funktionsname. Diese Infos stehen mir auch zur Verfügung(über Erl, GetThreadInfo), wenn das Script in einem Designelement (Form, Agent, ScriptLibrary, etc.) steht.
Was mache ich aber, wenn ich den Code in ASCII-Dateien auslagere und per %Include in die Designelemente einbinde?  Dann bekomme ich als Zeilennummer die Zeile geliefert, in der das %Include-Statement steht und als Funktionsnamen den Namen der Funktion, in der das %Include-Statement steht.

Wie komme ich zu sinvollen Informationen?
Hat jemand schon etwas auf diesem Gebiet geforscht?


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: Glombi am 31.10.03 - 09:27:44
Es bietet sich an, neben den von Notes mitgelieferten Bordmitteln noch was eigenes zu machen.

Bspw. in jeder Function/Sub :

Sub NameDerSub
Dim MODULE_NAME as String
MODULE_NAME = NameDerSub

 On Error Goto ErrHandler
  ... hier der Code
AfterError:
  Print "Routine Demo beendet"
Exit Sub

ErrHandler:
  Print MODLULE_NAME & ": Der Fehler mit Nummer " &  Str(Err) & " mit der Meldung " & Error$ & " ist bei Zeile " & Str(Errl) & " aufgetreten. Wir steigen aus"
  Resume AfterError:

End Sub


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: Semeaphoros am 31.10.03 - 09:28:54
Leider habe ich keine Notizen gemacht seinerzeit, wir hatten mal mit GetThreadInfo in der Error-Behandlung experimentiert, sind aber auch nicht wirklich glücklich geworden. Weder Erl noch GetThreadInfo lieferte uns zuverlässige Angaben über den Fehlerort, sobald irgendwelche Subroutinen oder Funktionen aufgerufen wurden. Mit Custom-Klassen haben wirs schon gar nicht probiert!

Ich selbst realisiere es schliesslich so, dass ich in jedem Modul eine eigene Fehlerbehandlung definiere und die Fehlerroutine, damit sie nicht immer neu geschrieben werden muss, als Subroutine ausgestalte, welche als einen der Parameter in der Regel den Namen des Moduls enthält. Damit bin ich aber auch plattform-unabhängig und bewege mich innerhalb des Standards (grade Errorhandling ist ja etwas, das man vielleicht auch mal in einem VBA brauchen kann :-)


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: animate am 31.10.03 - 10:02:24
den Namen der Fuktion, in der der Fehler auftritt, bekommt man mit Getthreadinfo(LSI_THREAD_PROC) - zumindest in R5. Ich benutze diese Funktion und sie hat noch nie ein falsches Ergebnis geliefert, auch nicht in eigenen Klassen.


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: Semeaphoros am 31.10.03 - 10:43:17
So viel weiss ich noch:
Wir haben versucht, eine generelle Error-Routine zu erstellen, die im HauptModul eingesetzt würde. Wenn sie angesprungen wird, dann sollte sie uns ModulNamen und die Fehlerzeile mitsamt den Fehlermeldungen angeben. Das hat eigentlich auch geklappt, der ModulName war nie ein Problem, wie Du richtig beschreibst. Nur mit der Fehlerzeile wars dann essig, die ist nicht zuverlässig rübergekommen. Aehnliche Probleme wie bei der Bord-Funktion ErrL, welche ja auch nur die richtige Zeile angibt, wenn die ErrorRoutine im selben Modul steht wie der auftretende Fehler. Damit waren wir aber nicht weit genug, um das Erstellen einer eigenen Fehlerroutine in jedem einzelnen Modul abzulösen.

Folgerung: Wenn ich eh in jedes einzelne Modul eine Errorroutine einbauen muss, dann bin ich mit GetThreadInfo eigentlich genauso weit wie mit Standard-Basic Bordmitteln auch, einzig den Modulnamen muss ich da von Hand jedesmal mit nachtragen, aber da ich ja eh pro Modul eine Routine habe, kann ich den auch gleich dort mit reinschreiben, so wie das Andreas oben schon vorgeführt hat (ok, wir machens ohne Variable, direkt inder Error-Routine, die Version von Andreas ist  flexibler, der Bearbeitungsaufwand für ein neues Modul etwa deselbe).


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: Rob Green am 01.11.03 - 10:11:27
das könnte als ergänzende Quelle dienen auch die Kommentare vaD!

http://www.lotusgeek.com/SapphireOak/LotusGeekBlog.nsf/plinks/ROLR-5MXR69

zB das hidden Feature hier:
But since 6 was released, there is a new 'undocumented' function lsi_info in my error handler stuff. the following can be done with the funciton:

lsi_info(1) = current line number
lsi_info(2) = current sub/function name
lsi_info(3) = current module
lsi_info(6) = lotusscript version
lsi_info(12) = name of lotuscript function that called this one, to build stack traces
lsi_info(50) = lotusscript memory allocated
lsi_info(51) = lotusscript memory allocated from os
lsi_info(52) = lotusscript blocks used


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: Glombi am 01.11.03 - 10:49:56
Gute Quelle,
insbesondere das On Error goto 0 deckt ja eine meiner Anmerkungen bzgl. Error handling in Subfunktionen und Ausgabe des Funktionsnamens ab.

Schon witzig, dass ausgerechnet an Halloween 2 unabhängige (?) Foren sich mit Error Handling beschäftigen.

Andreas


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: Rob Green am 01.11.03 - 10:55:52
ach so, der obige Link ist ein etwas älterer Artikel vor ca. 3 Monaten und stellt den Blog von Rocky Oliver dar (den Author von Teach Yourself Lotus Script und dem neuen Buch über R6 .. Volker Weber fand dat Buch nicht schlecht).


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: cpo am 08.11.03 - 10:02:36
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


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: Semeaphoros am 08.11.03 - 15:18:18
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?


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: TMC am 22.11.03 - 02:09:59
Hier noch der Hinweis zu einem anderen Projekt, wo die Ergebnisse von hier einfließen sollten:
Script Library (http://www.atnotes.de/index.php?board=11;action=display;threadid=12267)

TMC


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: TMC am 23.11.03 - 16:41:30
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


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: eknori am 23.11.03 - 17:08:48
@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



Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: koehlerbv am 23.11.03 - 20:05:38
Zitat
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


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: Semeaphoros am 23.11.03 - 20:11:28
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.


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: TMC am 27.11.03 - 23:25:33
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


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: TMC am 21.03.04 - 23:59:03
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


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: animate am 22.03.04 - 00:06:23
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)


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: animate am 22.03.04 - 00:09:35
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


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: TMC am 22.03.04 - 00:12:12
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?

 8)

Matthias


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: Semeaphoros am 22.03.04 - 00:14:03
Ja, oder noch komfortabler mit "On Error 91 Goto Hell"


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: TMC am 22.03.04 - 00:20:22
OK, prima, danke für die Tipps.

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


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: Semeaphoros am 22.03.04 - 00:40:17
Aehm, dann würde ich Dir empfehlen, den Error mit

Error 91

zu provozieren ...

:)


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: TMC am 09.04.04 - 17:25:35
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


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: TMC am 30.05.04 - 19:57:45
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


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: sja am 01.06.04 - 14:08:18
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


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: Glombi am 01.06.04 - 14:20:46
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
 


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: koehlerbv am 01.06.04 - 14:29:05
... 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


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: sja am 01.06.04 - 15:17:18
Hi Andreas,
hi Bernhard,

vielen Dank für so schnelle Hilfe.
Der Agent  mit
          On Error Resume Next
vor dem
          MailDoc.Send(False)
funktioniert. Es wird die Fehlermeldung in LOG-Datei, trotzdem Agent wird bis zum Ende ausgeführt. Ich verstehe, dass es keine schöne Lösung ist, aber als Übergangslösung es geht, da ich mit dem ErrorHandler noch nicht wo weit bin (es ist für mich etwas kompliziert).
Dazu habe ich eine Frage: wo findet man die Fehlernummern 4294 bzw. 4295? In der Datei lserr.lss habe ich die nicht gefunden

Vielen Dank
Sofia  



Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: Glombi am 01.06.04 - 15:23:54
Um an die Fehlernummer zu gelanden, kannst DU sowas machen

On Error Goto ErrorHandling

....

Exit Sub

ErrorHandling:
Print "Error" & Str(Err) & ": " & Error$
Resume Next


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: sja am 01.06.04 - 15:29:22
vielen Dank! ich probiere es


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: koehlerbv am 01.06.04 - 15:30:28
Diese Fehlernummern stehen in lsxbeerr.lss.


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: sja am 01.06.04 - 16:13:27
Herzlichen Dank!

und dann wieder eine Frage:
z. B. für lsERR_NOTES_NO_MATCH = 4294 habe ich versucht in der Notes-Hilfe, und in Google Erläuterung zu finden und wurde auch an der Datei lsxbeerr.lss adressiert. In der Datei steht nur CONST-Name und Fehler-Nummer.  Wo kann man Erläuterung dazu finden, da nicht immer intuitiv den Sinn der Fehler aus dem CONST-Name klar ist.   ???


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: koehlerbv am 01.06.04 - 16:18:50
Meines Wissens gibt es dafür keine Dokumentation. Die besten Erläuterungen bekommst Du nach dem Auftreten eines Fehlers aus den Variablen
Err (Fehlernummer)
Erl (Fehlerzeile) und vor allem
Error$ (die Klartextmeldung für den Client).

Bernhard


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: Glombi am 01.06.04 - 17:12:39
Nun, der Name lsERR_NOTES_NO_MATCH  sagt ja wohl alles aus, oder   ;)

Kein Match, also Error.


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: sja am 02.06.04 - 09:22:00
Hi Bernhard,
hi Andreas,

alles klar und danke schön  :)

Ach noch eine Frage: gibt es in der LotusScript bequeme Möglichkeit zur Überprüfung, ob die Adresse in der Dodomino-Verzeichnis erhalten ist? Die Möglichkeit, die ich mich vorstelle (Ansichte in names.nsf analysieren) finde ich nicht intelligent.

Gruesse und danke
Sofia


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: TMC am 02.06.04 - 19:48:22
Ach noch eine Frage: gibt es in der LotusScript bequeme Möglichkeit zur Überprüfung, ob die Adresse in der Dodomino-Verzeichnis erhalten ist? Die Möglichkeit, die ich mich vorstelle (Ansichte in names.nsf analysieren) finde ich nicht intelligent.

Bitte stelle die Frage in einem eigenen Thread, denn eigentlich geht's hier um Best Practices Errororhandling in Lotus Script  ;)

Danke.


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: sja am 02.06.04 - 20:03:40
Okay.
Entschuldigung bitte.


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: koehlerbv am 02.06.04 - 23:00:54
Kein Problem, Sonja. Der Thread passte ja am Anfang, dann ist er uns allen aus dem Ruder gelaufen.
Der liebe eknori AKA Ulrich Krause hat den Thread ja nun verschoben.  :)

Bernhard


Titel: Re:Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: TMC am 12.07.04 - 20:21:08
Hier noch 2 LDD-Artikel zum Thema "Debugging Lotus Script":

http://www-10.lotus.com/ldd/today.nsf/lookup/DebuggingLotusScript_1

http://www-10.lotus.com/ldd/today.nsf/lookup/DebugLS2


Titel: Re: Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: fritandr am 12.11.04 - 12:12:25
Hallo,

vielleicht ist es ja für einige interessant. Ich bin mir auch nicht sicher, ob das hier im Forum schon mal genannt wurde.

Julian Robichaux hat bei openntf eine Datenbank zum Thema Errorhandling und -logging eingestellt. Nachdem das Projekt wohl schon einige Zeit läuft, ist jetzt Version 1.0 draussen.

Beschreibung:
A database with script libraries that can be shared with all of your Notes databases, to provide common error and event logging across all of your applications. Works with both LotusScript and Java agents and libraries, and requires only a single function/method call with no parameters (okay, the Java method requires you to pass the Exception object, but that's all).

Logging your errors has never been easier or more efficient.


Es würde mich interessieren, was Ihr davon haltet.

Viele Grüße
Andreas


Titel: Re: Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: Semeaphoros am 12.11.04 - 12:15:44
Danke für diesen Hinweis, das ist mir entgangen, werde das dann auch mal studieren.


Titel: Re: Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: -Michael- am 13.11.04 - 19:57:27
@Jens:
Interessant wäre hier noch der spezielle Bezug auf Arrays.

Also typische Abfragen wie:
IsScalar
IsArray
IsEmpty
IsNull
Is Nothing

Also vielleicht ein Einzeiler was diese Abfrage bewirkt und wo man dies einsetzen kann.
Denn ich denke dies ist typisch z.B. für selbsterstellte Functions, wo man erst mal abfragen muss, ob denn das übergebene Variant überhaupt ein Array ist (IsArray), und man entsprechende Aktionen einleiten muss wenn der übergebene Wert Scalar ist (IsScalar).

Dann evtl. noch eine kurze Ausführung zu IsNull (dass dies eben nicht ein leeres String "" ist).

Ansonsten ist dieser Thread sehr hilfreich, vielen Dank dafür. Ich konnte daraus schon ein paar Infos für mich verwenden.

Michael


Titel: Re: Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: Semeaphoros am 13.11.04 - 20:02:49
Danke für die Anregung, das macht eminent Sinn.


Titel: Re: Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: animate am 13.11.04 - 20:31:25
offtopic

ist dir schonmal aufgefallen, das etwas keinen Sinn machen kann - sondern Sinn hat?

Nicht böse gemeint, ist mir nur in letzter Zeit öfter aufgefallen (nicht nur hier im Forum), dass alles plötzlich Sinn macht und nicht mehr hat. Kommt wohl aus dem Englischen...


Titel: Re: Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: Semeaphoros am 13.11.04 - 21:01:35
Jo, stimmt, und die Sprache bewusster zu verwenden, macht Sinn - diesmal wirklich :)

Andererseits ist Sprache durchaus etwas lebendiges und von daher gesehen eben auch nicht so scharf, wie wir uns das vor allem von unserer sonstigen Tätigkeit her gewohnt sind. In diesem Fall ist es aber eindeutig so: "hat Sinn" zu verwenden, macht tatsächlich Sinn ..... :)


Titel: Re: Best Practices: Error Handling in Lotus Script: Einleitung
Beitrag von: Johnson am 16.12.08 - 12:16:52
Nur zur Vervollständigung der lsi_info-Tipps:

LSI_Info: obscure but useful information in LotusScript: http://www.dominopower.com/issues/issue200606/00001780001.html

Calling all detectives - hacking Lsi_info together: http://www.geniisoft.com/showcase.nsf/archive/20040427-1043