Office: (Office 2003) Error handling

Hallo!

Da kann man 2 Arten von Fehlern unterscheiden.

1. Fehler die man mit dem "Wissen" der Prozedur beheben kann .. und dann auch entscheiden kann, dass die Prozedur oder die aufrufende Prozedur normal weiterlaufen kann
2. Fehler die nicht behoben werden können weil sie unerwartet waren und keine spezielle Fehlerbehandlung existiert. Diese Fehler gebe ich meistens an die aufrufende Prozedur weiter, damit der gesamte Ablauf abgebrochen wird. Ausnahme: die Prozedur macht nur ein paar unbedeutende Layout-Änderungen o. ä., dann ignoriere ich den Fehler auch manchmal und der Rest darf weiterlaufen.

Ob wiederverwendbar oder nicht ist meiner Ansicht nach eher egal.
Das Schwierige bei einer Fehlerbehandlung in einer Prozedur ist die Entscheidung, ob sie den unerwarteten Fehler aufheben darf oder an die aufrufende Prozedur weitergeben muss.
Wenn sie einen Fehler aufhebt, obwohl er nicht beseitigt wurde und dadurch z. B. ein falscher Rückgabewert erzeugt wird, ist in meinen Augen ein schwerer Designfehler, weil die übergeordnete Prozedur so weiterläuft als wäre nichts passiert statt ebenso in die Fehlerbehandlung zu laufen.
Die Lösung ist einfach: in der Fehlerbehandlung der Hilfsprozedur wieder einen Fehler auslösen, falls der Fehler nicht behoben werden konnte.

Aber was macht man bei Prozeduren, die einerseits als Hilfsprozeduren innerhalb anderer Prozeduren dienen, aber z. B. auch direkt die äußerste Aufrufebene darstellen - weil sie z. B. über die Menüs o. ä. aufgerufen werden?
Ich löste das bei meinen Anwendungen so, dass ich für Menüs & Co. eine extra Aufrufschicht dazwischen zog, um in dieser die Fehlermeldung auszugeben.

mfg
Josef

 

Juup, genauso habe ich es auch gemacht, bei Ribbon Callbacks mit kleineren Prozeduren habe ich allerdings gleich die OnAction-Prozedur an die globale Fehlerbehandlung angeschlossen ... aber dafür selbst jeden Form-Aufruf in einer eigenen Sub gekapselt. ^^

Stop ... ich bezog mich nur auf Deine Aussage das Prozeduren die nicht die oberste Aufrufebene darstellen, nicht zwingend eine eigene Fehlerbehandlung benötigen da sie ja auf die Fehlerbehandlung der aufrufenden Ebene zurück springen.

Und eben das wenn man sich darauf verlassen würde, es gerade bei viel wiederverwendbaren Code zu irgendwann chaotischem Ablauf kommen könnte, weil man selbst nicht mehr die Übersicht hat wohin der Code nun wirklich in aller Tiefe verzweigt und ob nicht vllt doch dann eine Prozedur mit einer eigenen Fehlerbehandlung angesprungen wird und das wäre die böseste Falle überhaupt wenn man sich auf den Rücksprung in die oberste Aufrufebene verlassen würde.

Wobei ja an sich die Validierung/Prüfung der Rückgabe meiner Ansicht nach Sache der aufrufenden Sub wäre. Da ich in den seltensten Fällen direkt in der aufgerufenen Sub entscheiden kann was passieren soll, zumindest dann wenn man sowas als wiederverwendbare Prozedur gestaltet hat die aus mehreren anderen Prozeduren angesprungen wird.

Z.B. Ersatzfunktionen ala FLookUp ... sowas hat bei mir sehr oft ein einfaches On Error Resume Next und die aufrufende Sub prüft dann was zurück kommt ... im Zweifelsfall bei Fehler Null/Leer und dann wird in der aufrufenden Sub entschieden was zu tun ist. Denke das wäre deutlich zuviel solche Entscheidungsmöglichkeiten in so einer Prozedur einzubauen ... da wäre dann wohl die Fallprüfung wirklich deutlich "größer" als die eigentliche Prozedur. ^^

Gruß

Rainer

 

Wenn keine der aufgerufenen Prozeduren eine Fehlerbehandlung hat, wird bis nach ganz oben abgebrochen. Das ist meiner Ansicht nach sogar sicherer als in einer der untersten Ebenen den Fehler abzufangen und aufzuheben, obwohl das Problem nicht behoben wurde bzw. keine spezielle Fehlerbehandlung wirksam werden konnte.
Anm.: wer weiß, was sein Code macht, wird damit kein Problem haben, mir fällt nur leider zu oft auf, dass viele Anfänger die Empfehlung "In jeder Prozedur muss eine Fehlerbehandlung sein" zu oft so umsetzen, dass sie in der Fehlerbehandlung den Fehler für die übergeordneten Prozeduren aufheben obwohl das Problem nicht beseitigt wurde.

Wobei ja an sich die Validierung/Prüfung der Rückgabe meiner Ansicht nach Sache der aufrufenden Sub wäre.

Wenn mir eine Funktion einen Wert zurück gibt, erwarte ich eigentlich schon, dass das ein gültiger Wert ist und ich nicht noch einmal prüfen muss, ob dieser Wert ein Wert ist, der von einem Fehler stammt.

Dann zeig mir bitte, wie du folgendes prüfst:
Code:

Und jetzt bau bitte diese Prozedur (mit einer Fehlerbehandlung, die den Fehler aufhebt) in eine andere Prozedur ein, in der du prüfst, ob die Rückgabe stimmt. *wink.gif*

Wenn du konsequent in der aufrufenden Prozedur das Ergebnis prüfen willst, müsstest du eine Prüfvariable verwenden und in getIrgendeineIntZahl z. B. einen ByRef-Parameter einbauen.
Über diese Variante dachte ich schon einmal nach, nutzte sie aber nicht, weil der Code in der aufrufenden Prozedur damit viel schlechter lesbar wird.
Ich finde zumindest die Verlagerung in den Fehlerbehandlungsteil für Ausnahmezustände übersichtlicher als wenn direkt im Code mit den Ausnahmen umgegangen wird. (Anm.: Ausnahme != erwartete Fehleingaben vom User)

Zum Beispiel mit FLookup:
Bei so einer Ersatzfunktion halte ich mich eigentlich an die Basisfunktion - in diesem Fall DLookup. Wenn ich mit dieser Funktion einen Wert aus einer Tabelle abfange, die es nicht gibt, wird ein Fehler ausgelöst. Frage ich einen Wert aus einer vorhandenen Tabelle mit einem Filter ab, der kein Ergebnis liefert, wird Null zurückgegeben. Falls letzteres in der aufrufenden Prozedur nicht sein soll, ist das natürlich entsprechend zu behandeln. Das entspricht aber keiner Ausnahmebehandlung sondern ist meiner Ansicht nach ganz normaler Ablaufcode.

Aus diesem Grund gebe ich den Fehler an die aufrufende Prozedur weiter und lasse die entscheiden ob sie sich selbst auch abbricht, eine spezielle Fehlerbehandlung startet oder ob sie weitermacht als wäre nichts passiert.

mfg
Josef

 

Am besten, man gibt immer einen Typ/Klasseninstanz zurück, der/die aus zwei Teilen besteht:

• dem eigentlichen Wert
• der Angabe, ob der Wert ernstzunehmen ist oder nicht *biggrin.gif* (Metainformation)

 

\@Martin: dein Vorschlag wäre ausbaufähig. *biggrin.gif*
Wenn in der Klasse z. B. die Wert-Eigenschaft noch als Standardeigenschaft definiert wäre, würde die Funktion auch direkt das Ergebnis liefern können (außer bei Rückgabe einer Objektreferenz).
Und wenn dann jemand mehr wissen will, speichert er die Rückgabe-Instanz in eine extra Variable und kann dort dann auf IsError u. ä. prüfen. *Smilie

mfg
Josef

 

Was ist ein gültiger Wert? Weisst Du das im vorhinein für alle Fälle des Aufrufes bei wiederverwendbarem Code? Das weiss doch an sich nur die aufrufende Sub was für Sie ein gültiger Wert ist ... 0 kann ein gültiger Wert sein aber auch kein gültiger Wert, abhängig davon was die aufrufende Sub damit vor hat. Oder sehe ich das falsch?

Grundsätzlich würde ich von Deiner Beispielsfunktion jetzt einen numerischen Rückgabewert erwarten. Diese Erwartung würde ich auch in der Prozedur so einbauen das im Zweifel/bei Fehler o.ä. nichts/Null zurück gegeben wird ... was beim einem Zahlentyp als Rückgabe eben enorm schwer ist, da er im Zweifel immer einen nummerischen Wert zurück gibt.

Daher wäre meine Wahl in diesem Falle Variant als Rückgabe und nicht Double und die aufrufende Sub entscheidet nun an Hand der Rückgabe ob gültig oder nicht. Und im Fehlerfalle sorge ich dafür das die Rückgabe eben Null ist und nicht 0 was ja durchaus ein gültiger Wert sein könnte.

Aber in der Prozedur selber kann ich mMn ja nicht entscheiden welcher Wertebereich gültig sein soll ... für den einen Aufruf ist es nur wichtig das es ein nummerischer Wert ist, für einen anderen Aufruf z.B. wären nur Werte im Bereich von 10 bis 100 gültig und im nächsten Aufruf wären nur negative Werte gültig.

Vor allem kann es durchaus auch sein, dass ich an einer Code-Stelle die Rückgabe als Fehler brauche um zu entscheiden wie der Code weiter verzweigen soll. Da wäre es mir mehr als unrecht wenn ich das über den Error-Handler abhandeln muss, weil ich an dieser Stelle absolut bewusst mit der Möglichkeit einer fehlerhaften Rückgabe rechne ... und warst nicht Du es, der gesagt hat das er es überhaupt nicht gut findet Programmentscheidungen an die Fehlerbehandlung zu koppeln? *wink.gif*

Klar kannst Du das alles in der Sub selber prüfen, allerdings musst Du dann eine Übergabe welcher Natur die Prüfung sein soll programmieren und dann eine vllt etwas umfangreichere Fall-Entscheidung.

Na ja ... wenn zur Laufzeit eine Abfrage auf eine Tabelle die es nicht gibt abläuft, dann stimmt was gewaltig nicht und das wäre für mich nicht mehr normaler Ablaufcode. ^^

@ Artrus

Das wär's. ^^

EDIT: Wobei machbar wäre es ja ... im Prinzip habe ich ja eigentlich schonmal was dazu gebastelt.

EDIT2 @ Josef: Genau für solche Rückgabeprüfungen könnte man die Klasse WhiteBoxTesting verwenden. ^^

Gruß

Rainer

 

Alle Werte, die keinen Fehler auslösen, sind aus Funktionssicht gültige Werte.
Ob diese Werte dann im Gültigkeitsbereich der aufrufenden Funktion liegen, ist dort zu entscheiden. Bei Fehler allerdings 0 zurückgeben, ist ein schlechte Lösung, falls 0 im grundsätzlichen Gültigkeitsbereich der Funktion liegen kann.

Nur weil du eine Fehlerbehandlung umgehen willst, führst du eine typunsichere Rückgabe ein?

Bitte noch einmal diesen Absatz lesen:

=> Wenn eine Tabelle nicht vorhanden ist, wird ein Fehler ausgelöst. Wenn mit einem Filter kein DS geliefert wird, wird NULL zurückgegeben.

Ja und? Was hat ein Ablaufcode mit einer Ausnahmebehandlung zu tun? Such dir bitte einmal diese Behauptungen von mir raus und lies sie im Zusammenhang mit den anderen Beiträgen. Ich bin mir ziemlich sicher, dass dort etwas mit On Error resume next vorkommt.
z. B. irgendetwas auf diese Art:
Code:

.. also so etwas, wo man einen Fehler erwartet um ein Ergebnis liefern zu können. Diese "Programmieren mit Fehlern" vermeide ich, da ich dann nur noch mit aktivierter Fehlerbehandlung entwickeln könnte und während der Entwicklung mit aktivierter "Unterbrechen bei jedem Fehler"-Option nicht mehr davon profitieren kann, wenn bei einem Fehler exakt die Fehlerstelle beim Debuggen markiert wird.

Wenn du aber an eine Prozedur einen Parameter übergibst, der dazu führt, dass das Ergebnis nicht berechnet werden kann, finde ich es richtig, wenn ein Fehler ausgelöst wird. Du hast ja im Prinzip in der aufrufenden Prozedur etwas übergeben, dass die Funktion nicht ordnungsgemäß arbeiten lässt.

Oder hat du das Code-Beispiel als Real-Code betrachtet? Dann muss ich mich für die Verwirrung entschuldigen, aber mir ist kein besseres Beispiel als 1/0 eingefallen, um einen Fehler zu erzeugen. Wenn ich weiß, dass bei einer Prozedur ein Fehler auftritt, wenn 0 als Parameter übergeben wird, würde ich das natürlich bereits vor dem Aufruf der Prozedur prüfen.
Nehmen wird die Log-Funktion als Beispiel: Log(0) wird zu einem Fehler führen. Wenn ich nun nach deinem Konzept gehe, müsste ich eine Ersatzfunktion für Log erstellen, die z. B. eine Variant-Rückgabe mit NULL hat, damit ich ich bei 0 NULL erhalte und dann im Code auf NULL prüfen kann. Ich betrachte es aber eher als einen Fehler, wenn 0 als Parameter für die Log-Funktion verwendet wird und finde es vollkommen in Ordnung, wenn die Log-Funktion durch Auslösen eines Fehlers meckert, statt einen Dummy-Wert zurückzugeben.

mfg
Josef

 

sehr interessante Diskussion hier... anfangs hatte ich noch fast ein schlechtes Gewissen, weil ich in meinen Werken eigentlich noch nie eine Fehlerbehandlung eingebaut hab... Allerdings sind in den Endfassungen auch immer alle Fälle abgeprüft, die einen Fehler verursachen könnten.. wie Division durch 0. Ich war wahrscheinlich aber auch noch nie in einer Situation, in der ich zu einer Fehlerbehandlung wirklich gezwungen wäre weil ich schon alles im Programmablauf abfangen kann.
Macht das Netzwerk in der Firma die Grätsche hängt Access sich eh ganz weg, da dürfte auch keine Fehlerbehandlung mehr greifen.
Ein Entwickler, der für Kunden entwickelt, muss natürlich ganz andere Ansprüche haben...

 

Martins Vorschlag aus #19 ist ja so dumm nicht.
Korrekt wäre es an sich immer, als Rückgabe immer den Erfolg (Bool) zurückzugeben, während das Ergebnis in einer übergebenen ByRef-Variablen steht.
Zumindest sind praktisch alle Funktionen des Windows-API so aufgebaut. Die geben in der Regel ein S_OK (=0) in HResult zurück, wenn die Funktion klappte. Erst dann muss man sich um die übergebene Result-Variable kümmern.
Das macht den Code meist natürlich länger, weshalb in VB halt die kürzere Variante gewählt und stattdessen auf Auslösung des Fehlers reagiert wird.

Ciao, Sascha

 

Genau deswegen lasse ich mir sowas als Variant zurück geben, wenn es mir wichtig ist einen Fehler in der aufrufenden Sub zu behandeln ohne das ich hier unbedingt in die Fehlerbehandlung reinrutschen will.

Wieso typunsicher?

Mit 'if VarType(RückgabeWert) = vbDouble then' hätte ich jetzt für die Prüfung ob ein gültiger Wert zurück gekommen ist aus der Funktion exakt alles abgedeckt, selbst Null. Und brauche dafür nicht die Fehlerbehandlung zu bemühen um festzustellen ob die Funktion einen Fehler produziert hat oder nicht.

Ich finde das mehr als typsicher ... okay, aber wahrscheinlich verstehe ich mal wieder nur mal was komplett anderes unter dem Begriff als Du. ^^

Genau das meine ich doch ... und 0 kann für die eine aufrufende Sub ein Fehler sein weil ein wert größer 0 erwartet wird und für die andere Sub kann die Rückgabe Null ein korrekter Wert sein ... korrekt in dem Sinne zu entscheiden das hier was schief gelaufen ist und deswegen eine andere Verzweigung genommen werden muss.

Sorry, da sehe ich es durchaus als schlicht sinnvoll an das die Porzedur das macht was Sie soll und nicht selbst auf Fehler o.ä. reagiert, sondern diese in der aufrufenden Sub abgehandelt werden und die jetzt für sich prüft ob der Wert gültig ist ... nicht nur aus Code-Sicht sondern auch aus der Sicht der Programmlogik heraus.

Juup, habe ich natürlich ... kennst mich doch. ^^

Okay, ich denke das ist wohl klar ... aber die Frage wäre dann bei speziell diesem Beispiel wie macht man nun der aufrufenden Sub klar das die Rückgabe 0 kein Ergebnis der Funktion, sondern des Ergebnis eines Fehlers ist?

Würde ich das ohne Variant-Typ lals Rückgabe lösen wollen gäbe es nur die Möglichkeit entweder einen boolschen Wert - wie von Martin - vorgeschlagen mit zurück zu werfen oder eben die Prozedur satt in die Fehlerbehandlung rasseln zu lassen damit die aufrufende Sub mitbekommt das ein Fehler aufgetreten ist.

Darum ging es mir im Prinzip: Schlicht um Sachen wo man durchaus mal mit Fehlern rechnen muss weil z.B. der User an sich sinnige aber in der Kombination/Reihenfolge unsinnige Angaben macht. Und man kann ja nun wirklich nicht alle möglichen Kombinationen auf Sinn prüfen.

Habe ich ja auch nie gesagt das man das so machen sollte ... sondern nur das es die einzigste Möglichkeit wäre wenn man wollte- z.B. zur Fehlervermeidung um die es ging - einen String-Key einer Collection auf Exist zu prüfen.

Gruß

Rainer

 

Natürlich soll eine Prozedur das machen, wofür sie geschrieben wurde. Ich verstehe nur den Sinn nicht, warum man in Hilfsprozeduren einen Dummy-Wert zurückgeben soll, wenn es dort zu einem Fehler kommt, dann den Fehler aufhebt und in der aufrufenden Prozedur auf den Dummywert reagiert, weil der ja aus einem Fehler entstanden ist. Bei den Dummy-Werten gibt es dann sogar noch die Schwierigkeit, dass man unterschiedliches verwenden muss, weil auch NULL einmal ein gültiger Rückgabewert einer Funktion sein könnte. So etwas führt meiner Meinung nach nur zu schwer verständlichem Code, den nur der einigermaßen sicher bedienen kann, der die Hilfsprozeduren geschrieben hat. *Smilie
Bevor so etwas einbaue, mache ich es lieber so wie in den (von Sascha bereits erwähnen) API-Funktionen und liefere als Funktionsrückgabe immer nur einen Wert der angibt, ob die Ausführung erfolgreich war und gebe den eigentlichen Rückgabewert an einen ByRef-Parameter weiter.

Anm: Wir diskutieren hier schon noch über Fehlerbehandlung von Ausnahmen und nicht von Logik-Prüfungen, oder?
(Dass man ein die Log-Funktion keine 0 übergeben darf, ist für mich Programmcode und keine Fehlerbehandlung. Sobald mir die Log-Funktion einen Fehler wegen 0 liefert, habe ich vorher schon gemurkst, weil ich diese erkennbare Fehlerquelle nicht prüfte. Das Gleiche gilt für Division durch 0.)

mfg
Josef

 

Da in dem Beispielfall eine Division durch 0 zu einem Fehler führt, reden wir schon noch über eine Fehlerbehandlung.

Da viele Fehler auch abhängig sein können von der Programm-Logik, denke ich aber schon das Prüfung der Programmlogik genauso ein Teil der Fehlerbehandlung sein muss. Für die eine Programmlogik ist es schon ein Fehler wenn eine 0 als Wert übergeben wird und für die andere Programmlogik kann das durchaus vorkommen und auch gültig sein.

Ist dann die Division durch 0 immer ein Fehler? Aus Compiler Sicht natürlich, aus Programm-Logik Sicht nicht zwingend.

Z.B. könnten die übergebenen Zahlen aus einer vom User dynamisch erstellten Abfrage stammen, dann wäre 0 aus Programm-Logik Sicht ein gültiger Wert. Würde als Ergebnis der Abfrage gleich eine Berechnung mit den Abfrage-Ergebnissen mit erfolgen wäre es aus Programm-Logik Sicht nicht sinnvoll den Ablauf der Berechnung und Ausgabe der Abfrage-Werte mit Berechnungs-Ergebnissen zu unterbrechen weil eine Berechnung nicht durchgeführt werden konnte.

Und daher meine Sichtweise: Klar vermeidet man, dass man bei solch erkennbaren Fehlern das Kommando ausführen lässt - in unserem Falle eben die Division durch Null - aber ich würde eben aus obigen Gründen hier keine Fehlerbehandlung drinnen haben wollen, sondern eben nur der aufrufenden Sub mitteilen das eine Berechnung nicht erfolgen konnte ... soll die dann aus Programmlogik-Sicht entscheiden was damit zu tun ist.

Wie Du es letztendlich machst ist doch egal, mir ging es nur eben bei dem Beispiel darum das es nicht immer sinnvoll ist oder sein muss das man einen Fehler direkt in der aufgerufenen Sub behandelt sondern den Umgang mit dem Fehler der oberen Aufrufebene überlässt, weil die i.d.R. die Programm-Logik beinhaltet und die Reaktion auf einen Fehler eben in meinen Augen eine Sache der Programm-Logik ist.

Wenn ich - egal wie - einen Fehlerwert zurück gebe wenn die Funktion nicht erfolgreich war, dann kann ich auf eine Fehlerbehandlung im eigentlichen Sinne verzichten, sondern muss nur sicher stellen das es keinen Laufzeitfehler gibt aber die Behandlung an sich überlasse ich dann der oberen Aufrufebene.

Und das war letztendlich meine Aussage und der Grund wieso ich z.B. in Ersatzfunktionen wie FLookUp sehr oft mit On Error Resume Next arbeite. Ob ich nun einen boolschen Wert auf True für erfolgreiche Berechnung prüfe oder einen Variant-Wert auf Null als Rückgabe ist dabei für den Programmablauf egal.

Aber zugegeben, mittlerweilen arbeite ich auch mehr mit der Rückgabe eines boolschen Wertes und die Übergabeparameter kommen dann als ByRef-Werten ... die WhiteBoxTest-Klasse - die Du ja kennst - legt das natürlich nahe. *wink.gif*

Gruß

Rainer

 

Hi,

das scheint auch die künftige Linie zu sein. VB.Net macht das z.B. bei Date.TryParse auch so. Rückgabewert ist ein Boolean, der den Erfolg anzeigt, und der geparste Wert steht in einer anzugebenden Variable.

 

Dann verstehe ich dich vermutlich falsch. Wenn du in der ausführenden Prozedur den Fehler nicht behandelst, wird er in die aufrufende Prozedur weitergereicht.
Ich war der der Meinung du willst den Fehler behandeln und sogar aufheben - und in der aufrufenden Prozedur nur noch auf einen Wert reagieren, der außerhalb des Wertbereichs der "richtigen" Rückgaben liegt. Diese Vorgehensweise finde ich unübersichtlicher, als wenn der Fehler nach oben weitergereicht wird.

Dort ist es aber auch Aufgabe der Methode, etwas zu versuchen. Es gibt genügend andere Methoden (z. B. DateTime.Parse) in .net, die einen Fehler auslösen, wenn man von ihnen etwas haben will, das sie nicht liefern können. *wink.gif*

Wenn es die Aufgabe einer Prozedur ist, einen möglicherweise auftretenden Fehler abzufangen und aufzuheben und dann eine entsprechende Rückgabe zu liefern ist ja alles in Ordnung. Mir ging es aber eher um jene Prozeduren bei denen man das nicht sofort erkennt, dass sie Laufzeitfehler abfangen und aufheben.

So etwas sehe ich z. B. viel zu oft in Beispiel-Anwendungen:
(Zur Sicherheit: das ist nur ein symbolischer Code)
Code:

So ein Ablauf ist in meinen Augen ein Murks.

Wenn man beim Programmieren bereits erwartet, dass in "aufgerufeneProzedur" Fehler auftreten, könnte man ein Rückgabe einbauen, die in der aufrufenden Prozedur eine Prüfung ermöglicht.
Code:

Wenn aber sowieso abgebrochen werden soll, wenn die Prozedur fehlschlägt, würde ich einfach den Fehler nach oben weiterleiten, dann kann die aufrufende Prozedur entscheiden, ob sie abbricht bzw. den Fehler wieder in die nächst höhere Aufrufebene weiterleitet.
Diese Variante nutze ich zumindest in meinen Anwendungen bei nicht erwarteten Fehlern.
Typischer Fall: Serververbindung ist weg und ist auch nach ein paar Versuchen nicht wieder herstellbar. Wenn dieser Fall eintritt, will ich als Ergebnis von der DLookup-Ersatzfunktion keine NULL erhalten sondern den Serverausfall mitbekommen, damit ich die gesamte Aufrufhierarchie abbrechen kann.

Im Prinzip sind viele Varianten möglich, wie man das Problem lösen kann. Nur eine Fehlerbehandlung in eine Sub einbauen, reicht allerdings nicht aus, wie man hoffentlich im obigen Code sehen kann.

mfg
Josef

 

Ist nicht alles Programmieren ein Versuch? *philosphier*