Best Practices > Diskussionen zu Best Practices
Best Practices: Error Handling in Lotus Script: Einleitung
koehlerbv:
--- Zitat ---Wie würde man denn als Rückgabewert der Funktion ein True / False einbauen und Fehlertext im False-Fall?
--- Ende Zitat ---
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
--- Ende Code ---
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)
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln