error handling

[littleS]

Hallo,

macht das zweite "Exit Sub" Sinn?

Code

Sub SubName
  On Error Goto myerrhandler
  
  .....

  Exit Sub
myerrhandler:
  MessageBox "frmTest SubName(): " & Erl & ": " & Error$
  Exit Sub  '// <-- macht das Exit Sub Sinn? 
End Sub

[Semeaphoros]

Wenn man strukturierte Programmierung streng anwendet, müsste man mit einem Resume vor das eigengliche Exit Sub springen und wenn die Sub auch wirklich gut pflegbar sein soll, würde ich das auch so machen (sprich es gibt genau ein einziges Exit Sub). Dann bleiben eventuell notwendige Endverarbeitungen, die auch im Fehlerfall durchgeführt werden müssen, sicher an einem Ort und werden nicht vergessen.

[Marinero Atlántico]

Hi,

ich stimme mit Jens nicht überein.
Für meinen Geschmack ist das 2. Exit Sub völlig in Ordnung.
Die Intention der Vorgabe nicht mehrere Ausstiegspunkte aus einer Subroutine zu haben, liegt darin, dass es sehr verwirrend sein kann, besagte Ausstiegspunkte zu finden.
Wenn man das eine KOnvention für Errorhandling macht (das 2. Exit Sub), dann ist das für meinen Geschmack eine Konvention, die völlig in Ordnung ist.
Die Intention von Designrichtlinien sind imho wichtiger als fragwürdige, starre Regeln.

Hier ein satirischer Beitrag des einzigartigen H. Suleiman, über Compiler, die anhand von zu starren Designrichtlinien Meldungen abgeben, die keine Fehler sind:

Foolishly, I upgraded to jikes 1.21. Every time I compile now, I want to immolate those chocolate log miners. I am filled with such rage, such fury, that no punishment or torture method seems severe enough to slake my thirst for revenge and retribution.

Why in god's name do I need to be informed, by default, of every time I use a local variable to shadow a member field? Why can't I not specify a break in my switch statements if I so choose? The language allows both and has VERY explicit clear rules about what happens and how it's treated. If it's good enough for the goddam JLS, it's good enough for me. You, jikes twats, have NO right deciding my coding habits for me. You're a bunch of fuckwitted angsty IBMers who think that all they need to do is tug some linux/OSS penis to be admired and loved by all.

It's one thing to write a custom compiler for children just taking their first java steps. It's quite another to foist this disgusting filth onto people who supposedly know what they're doing. I mean, we can forgive the fact that it emits different bytecode to javac (look at the code generated for asserts, for example), we can forgive the fact that its website is one of the most difficult to navigate or find any info at, but really, even us seasoned bitter cynics have our limits.

http://www.jroller.com/page/fate/?anchor=jikes_authors_are_terrorists
Axel

[Semeaphoros]

As you like, Axel, ich hab das bewusst nicht so formuliert, dass man mir glauben muss .... 

Trotzdem, wenn Du das Exception - Handling in jüngeren Sprachen wie Java oder auch Delphi-Pascal ansiehst, wirst Du finden, dass dort genau für das von mir angetönte Problem eine Lösung zur Verfügung gestellt wird: Code, der ausgeführt wird unabhängig davon, ob ein Fehler auftrat oder nicht, und genau zur Sicherstellung, dass das auch klappt, macht die "nurEinExitPunkt" Strategie eben Sinn, es sei denn, der Compiler beherrscht das, so wie bei einem Ojekt der Destruktor, den gibts aber bei einer Sub nicht.

[littleS]

Hallo,

danke erstmal. So weit hatte ich das ganze nicht durchdacht, mir ging es erstmal darum, ob ein "Exit Sub" notwendig ist, wenn direkt danach ein "End Sub" kommt. Welcher Unterschied besteht denn zwischen

Code

  Exit Sub  <-- Funktion läuft fehlerfrei durch und wird hier verlassen !?
myerrhandler:
...
End Sub

und

Code

  Exit Sub
myerrhandler:
  MessageBox ...
  Exit Sub <-- Fehler trat auf und Sub wird hier verlassen
End Sub

bzw.

Code

  Exit Sub
myerrhandler:
  MessageBox...
End Sub  <-- Fehler trat auf und sub wird hier verlassen

s.

[koehlerbv]

Ohne Exit Sub oder Resume Sprungmarke nimmst Du den entstandenen Fehler mit in die aufrufende Routine. Exit Sub setzt Err = 0.

Bernhard

[littleS]

Danke. Also falls ich den Fehler nicht der aufrufenden Routine (nochmal) behandeln möchte, dann macht es Sinn, "myerrhandler" mit "Exit Sub" zu verlassen.

Dann werd ich mal die DesignerHilfe bemühen, um noch etwas tiefer in die Thematik einzutauchen.

s.

[TMC]

Für meinen Geschmack ist das 2. Exit Sub völlig in Ordnung.

Ist wohl schon Geschmackssache, aber ich sehe das nicht so.

Code

On Error goto ErrHandler
'code
Exit Sub
ErrHandler:
'print "irgendwas'
End Sub

Sobald im ErrorHandler, kommt dann bei 'End Sub' eine "No Resume"-Fehlermeldung.
Da jetzt einfach eine "Exit Sub" reinzuschalten, finde ich persönlich nicht als "schön". Denn erstmal ist so nicht ersichtlich, dass Exit Sub ein Err=0 macht. Siehe auch die Frage oben von littleS als Auslöser dieses Threads.

Meines Erachtens ist es durchgängiger, hier mit 2 Sprungmarken zu arbeiten:

Code

On Error goto ErrHandler
'code
GoOut:
Exit Sub
ErrHandler:
'print "irgendwas'
Resume GoOut
End Sub

Wenn man das immer so macht, hat das noch einen Vorteil. Statt ExitScript verwendet man immer GoOut, also auch z.B. bei anderen Prüfungen/If-Abfragen etc. Im GoOut kann man dann noch was anderes machen, was allgemein immer gemacht werden soll, wenn man die Routine verlässt.
Man sollte das IMHO aber dann durchgängig machen, und ansonsten Sprungmarken immer vermeiden.

Außerdem ist es so schön durchgängig: Eine Fehlerbehandlung wird immer sauber durch ein Resume beendet.

Aber wie schon erwähnt: ist wohl "Geschmackssache". Am wichtigsten ist IMHO, das immer gleich zu machen, zumindest für ein Projekt.

[Glombi]

Ich verwende auch nie das Exit sub sondern immer ein Goto EndOfModule oder Goto GoOut wie Matthias.

Der Grund ist einfach: Wenn ich eine Sub in eine Function oder umgekehrt ändere, muss ich alle Exit Sub als Exit Function bzw. andersherum programmieren. Und das ist unnötige Arbeit!
Und da ich viel mit Copy Paste bzw. Vorlagen arbeite, ist es so immer nutzbar.

Andreas

[koehlerbv]

Ich halte es hier mit Axel, dem Seemann. Hauptsache, man verwendet eine stringente Regel - meines Erachtens sollte diese nicht nur auf ein Projekt bezogen sein, wenn man sich mal entschieden hat.

Ein Goto LeaveModule ist genauso gut oder schlecht wie ein oder mehr Exit <module> (ob nun Sub oder Function) - es muss einfach in das Konzept passen und dann entsprechend durchgezogen werden.

Wichtiger sind meines Erachtens sowie folgende Punkte:
- Wie wird einheitlich den aufrufenden Modulen mitgeteilt, dass der Aufruf der Unterroutine in die Hose gegangen ist ?
- Wie sorge ich dafür, dass auch logische (also non-run time ) Fehler der aufrufenden Routine ihre Not signalisieren ?
- Sorge ich ordentlich vor, dass alle eindeutig vorher erkennbaren Fehlerzustände ohne ErrorHandler abfange ? Ich denke hier nur an auch hier im Forum immer wieder geposteten Code, der irgendein Objekt versucht zu instantiieren und sich dann darauf verlässt, dass das Objekt auch wirklich vorhanden ist (Set item = doc.GetFirstItem (.... usw. )

Bernhard