VBA On Error GoTo errHandler

Question

Hallo zusammen,

ich überlege wo die Platzierung meines errHandlers am sinnvollsten
ist.
Könnte ich den und die "On Error Goto errHandler"-Anweisung zum
Beispiel in ein WorkbookOpen Sub einbauen, sodass die für alles
folgende gilt?

Oder muss ich in jedes Sub ein "..GoTo..." und ein "errHandler:"
einbauen?

Beste Grüße,

Answer 1

auf diese Sachen sollte man verzichten, fas jeder Fehler kann abgefangen werden.

Gruß Hajo

Answer 2

Hi,

es ist die Frage, ob ein ErrorHandler tatsächlich notwendig ist, denn viele Codes lassen sich so schreiben, dass es auch ohne geht. Da aber niemand deinen Code kennt, kann man auch schlecht etwas dazu sagen.

Bis später,
Karin

Answer 3

auf diese Sachen sollte man verzichten, fas jeder Fehler kann abgefangen werden.

Ein "On Error Goto ..." ist ja gerade dazu da, um Fehler abzufangen. Wie sollte man das sonst ordentlich machen?

mfg, Massaraksch

Answer 4

Wie sollte man das sonst ordentlich machen?

indem man den Code so schreibt, dass kein On Error Goto ErroroHandler erforderlich ist - in 99% aller Fälle ist das durchaus möglich.

Bis später,
Karin

Answer 5

indem man den Code so schreibt, dass kein On Error Goto ErroroHandler erforderlich ist - in 99% aller Fälle ist das durchaus möglich.

Das halte ich für für ziemlich umständlich und fehleranfällig. Vielleicht geht das ja bei einfachen Sachen.

Wie fängst du unerwartete Fehlersituationen ab? Beispiel: Zugriff auf eine Datei, die dummerweise gerade gesperrt ist oder ähnliches.

OK, man kann z.B. laufend IF THEN ELSE Konstrukte verwenden. Die sind allerdings unschön und unübersichtlich. Und ersetzen keinesfalls eine ordentliche Fehlerbehandlung.

Naja, jeder wie er denkt.

mfg, Massaraksch

Answer 6

ich zitiere mal aus Monica Can/Michael Schwimmer "Mircrosoft Offie Excel 2007-Programmierung - das Handbuch":

So genannte On Error- oder GoTo-Anweisungen genießen unter Programmieren generell einen schlechten Ruf, weil der Einsatz nicht ungefährlich ist. Nach Möglichkeit sollten Sie darauf verzichten und bessere Lösungen suchen.

Mit anderen Worten: besser "umständlich" (deine Worte) mit If- oder Case-Anweisungen programmieren und dadurch den Code sicherer machen, als eine Überschüttung des Codes mit On Error und dadurch das Heraufbeschwören der Gefahr, dass der Code etwas macht, was man als Programmierer gar nicht bezweckt hat. Und genau das passiert, wenn man insbesondere unerfahrenen Programmieren vorgaukelt, On Error sei das non plus ultra einer "ordentlichen Fehlerbehandlung". Jeder gute Programmierer bevorzugt die Verwendung von If- und Case-Anweisungen und bei stukturierter Programmierung, bleibt der Code auch völlig übersichtlich, im Gegensatz zu Sprunganweisungen, aber das sollte man als Programmierer eigentlich wissen.

Natürlich gibt es Situationen, in denen die Verwendung von On Error nicht zu umgehen ist, oder wo man sie ganz bewusst einsetzt, um ein bestimmtes Verhalten zu erreichen. Aber genau das unterscheiden zu können macht einen ordentlichen Programmierer aus und nicht, weil On Error angeblich "eine ordentliche Fehlerbehandlung" ersetzt - da bist du auf dem falschen Dampfer. ;-)

Bis später,
Karin

Answer 7

Ich habe es bis jetzt noch ohne OnError GoTo gemacht weil
ich bisher keinen Fehler mutwillig hervorbringen konnte. Habe alle
Eventualitäten abgefangen, an die ich denken konnte. Aber nur für den
Fall werde ich es noch einbauen.

Beste Grüße,
critchm

Answer 8

es hängt natürlich ganz vom Umfang des Programms und wofür es eingesetzt wird bzw. wer der/die Benutzer ist/sind, ob und ab wann die Verwendung einer Sprunganweisung wie On Error Goto ErrorHandler unbedingt erforderlich ist. Wenn du versucht hast, alle aus deiner Sicht möglichen Eventualitäten abzufangen, würde ich (für meinen Teil) erst einmal auf einen ErrorHandler verzichten und abwarten, ob bei intensiver Nutzung wirklich ein Fehler auftritt.

Wenn ich mich denn doch für die Verwendung einer Sprungmarke zum Abfangen eines Fehlers entscheiden würde, würde ich keine globale Lösung (wie im Workbook_Open) verwenden sondern nach Möglichkeit (bzw. Notwendigkeit wo ein Fehler auftauchen kann) für jede Prozedur einen eigenen ErrorHandler schreiben. Dann weißt du als Programmierer sofort, in welcher Prozedur der Fehler aufgetreten ist und was ihn ausgelöst hat - auf diese Weise ersparst du dir eine Menge Such-Arbeit. Außerdem ist es auch nicht immer ganz einfach, im Nachhinein zu rekonstruieren, wie der Fehler ausgelöst wurde, wohingegen das Wissen um Fehlernummer und Fehlerbeschreibung des Suchfeld schon rigoros einschränkt.

Aber - das ist meine ganz persönliche Meinung - das darf jeder halten wie er/sie es möchte. ;-)

Als Tipp würde ich dir zu diesem Thema diesen Link empfehlen: Link zur Seite

Bis später,
Karin

Answer 9

Der Link aus Antwort 8 ist sehr schön. Der gute Mann gibt gute Ratschläge :o)

www.online-excel.de/excel/singsel_vba.php?f=144

Fehlerbehandlung gehört sicherlich zu den ungeliebten Kindern von VBA. Es bedeutet Arbeit und man sieht nicht wirklich was dabei herauskommen. Dabei ist gute Programmierung ohne Fehlerbehandlung nicht vorstellbar.

Soviel zur Ablehnung einer ordentlichen Fehlerbehandlung.

Sollten Sie zu der Spezies gehören, die meint, 100 % sicheren Code auf allen Rechnern in jeder Umgebung zu produzieren, dann müssen Sie jetzt nicht weiterlesen, sondern sollten sich schnellstmöglich patentieren lassen.

Na dann mal los ;o)

Auch ein schöner Satz vom Autor:

Alle Fehler die auftauchen können, weiß nur der VBA Teufel und selbst der kennt nicht alle.

Beverly kennt sie alle ;o)

Noch eine Bemerkung zu:

Jeder gute Programmierer bevorzugt die Verwendung von If- und Case-Anweisungen und bei stukturierter Programmierung, bleibt der Code auch völlig übersichtlich, im Gegensatz zu Sprunganweisungen, aber das sollte man als Programmierer eigentlich wissen.

Das ist natürlich korrekt. Sprunganweisungen im normalen Code sind Bäh! und erinnern am Batch-Frickelei. Zur Behandlung von unerwarteten Laufzeitfehlern in VBA aber wohl unverzichtbar.

Wer kennt und liebt sie nicht, die für den Anwender nichtssagenden Meldungen wie "Laufzeitfehler XXX, Die Methode Y für Objekt Z ist fehlgeschlagen, Beenden? Debuggen?" und danach hängt das schöne Makromodul irgendwo im "Nichts".
Danke, "vorausschauender" Programmierer. Wozu gibts eigentlich das Err-Objekt?

Klar, für einfache Makros und übersichtliche Sachen muß man da keine Wissenschaft draus machen. Für den "Eigenbedarf" in Makros muß man sich nicht unbedingt damit befassen. Ist meistens Overkill.
Aber für professionelle Projekte sind die Unwägbarkeiten der verschiedenen Umgebungen kontrolliert abzufangen.Oder man ist man eben kein "richtiger Programmierer.
(ich bin übrigens auch keiner, sondern Sysadmin, der eher Scripte für den täglichen Bedarf frickelt)

Die Möglichkeiten des Errorhandling in VBA sind zwar nicht dolle (kein Try-Except oder Catch o.ä. wie in "richtigen" Programmiersprachen, hey das gibts sogar in der Powershell ;o) aber sinnlos sind sie nicht. Wieso sollte für VBA nicht gelten, was für ALLE anderen Programmiersprachen gilt?

mfg, Massarakasch

Answer 10

damit bestätigst du doch eindeutig, was ich geschrieben habe. Nur eins stimmt nicht: ich habe nirgendwo geschrieben, dass ich alle Fehler kenne - das behauptest du, nicht ich.

Bis später,
Karin