Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

Excel 2013 VBA für Profis

Fehler melden und beheben

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Excel VBA hat eine spezielle Art, mit Fehlern umzugehen. Sie müssen vorher ankündigen, was im Falle eines aufgetretenen Fehlers passiert und an welcher Stelle der Code dann weitermachen soll.

Transkript

Dieser Code erzeugt Fehler, bei Bedarf. Laufzeitfehler, die zum Beispiel daraus resultieren, dass ich mehr eingebe als eine Integer-Variable annehmen kann. Können wir mal eben gucken. Mit F5 gebe ich eine Zahl ein, die für Integer zu groß ist. Und nach dem OK gibt es diese Visual-Basic-Fehlermeldung. Mit Beenden ist das Problem erstmal beseitigt, aber ich will es ja nicht so beseitigen, dass ich jetzt Double als Datentyp annehme, sondern ich will damit umgehen. Das bedeutet als Erstes, ich muss dafür sorgen, dass ich die Gewalt über die Fehlerbehandlung bekomme. Und da befinden wir uns, das kann man nicht anders sagen, in der Steinzeit der Programmierung. Visual Basic ist eine sehr moderne Hochsprache. Die kann alles, was man so braucht. Nur in der Fehlerbehandlung haben Sie es zum Beispiel plötzlich mit Befehlen wie GoTo zu tun. Das ist ein Pfui für jeden Programmierer. GoTo benutzt man nicht, weil der Code völlig unübersichtlich wird. Aber in der Fehlerbehandlung ist das nötig. Wenn in dieser Zeile ein Fehler auftritt, oder ab dieser Zeile müsste ich sagen, dann muss ich vorher ankündigen, was dann passieren soll. Und zwar brauche ich irgendwo, das schreibt man typischerweise an das Ende der Prozedur, ein sogenanntes Label, das nannte sich früher auch schonmal Sprungmarke, also zum Beispiel sowas wie ZaehlerFehler. Und der Doppelpunkt sagt: Am Anfang der Zeile, Achtung, das ist ein Label, eine Sprungmarke. Es gab früher mal richtige Zeilennummern an der Stelle. Und dort mache ich irgendwas. Im Moment melde ich nur den Fehler: "Fehler Nr." Und da kann ich jemanden nach der Nummer fragen, das sogenannte Error-Objekt, das Fehler-Objekt, aber nur kurz geschrieben Err. Enthält zum Beispiel die Angabe, welche Nummer der Fehler hatte. Und zusätzlich, weil das so wenig aussagekräftig ist, kann noch Err.Description abfragen. Und weil das ja ein Fehler ist, schreibe ich noch vbCritical und dann noch die Konstante für meinen Namen, dass man nicht denkt, die Fehlermeldung käme von Excel, sondern die kommt eben von meinem Programm. Und hierhin springe ich, wenn ein Fehler auftritt, oder auf Englisch: On Error, wenn ein Fehler auftritt, GoTo, springe dorthin, nämlich wo ZaehlerFehler genannt ist. Ab dieser Zeile wird bei jedem Fehler nach da unten gewechselt. Das können wir mal direkt testen mit F5. Das ist mein Zähler. Ich erzeuge jetzt einen Fehler. Und mit OK springt er direkt hier in meine MsgBox. Nach dem OK alles super. Allerdings, wenn jetzt kein Fehler auftritt; ich schreibe mal ganz normal 123, hier durch 7; werden Sie jetzt überrascht feststellen nach dem OK gibt es einen "Fehler Nr. 0", ohne Description, ohne Beschreibung. Nach dem OK sehen Sie auch, er hat hier gerechnet. Also er ist durch diese Zeile gelaufen und dann allerdings weitergelaufen. Das ist nicht abweisend hier, der läuft einfach durch. Deswegen, um das zu verhindern, müssen Sie vorher Exit Sub schreiben. Wenn ein Fehler auftritt, hier zum Beispiel springt er über Exit Sub hinweg und führt diese Zeile aus. Wenn kein Fehler auftritt, wird jede Zeile nach der anderen ausgeführt und hier verlässt der Code die Prozedur. So weit ist alles gut. Den ersten Fehler haben wir behandelt. Und da es einen zweiten Fehler gibt, möchte ich den getrennt behandeln. Also, hier ändere ich schonmal die Sprungmarke. Es ist jetzt ein NennerFehler und ich schreibe das auch mal hier in den Text rein. Das ist ein "Zähler-Fehler", damit wir die unterscheiden können, und das ist ein "Nenner-Fehler". Sonst brauchen wir da nichts dran zu ändern. Also, das können Sie direkt entsprechend kopieren. Da steht jetzt einfach nur Nenner an der Stelle. So weit alles in Ordnung. Ich werde jetzt mal einen NennerFehler provozieren, dass Sie sehen, dass er wirklich da hinspringt. Also mit F5, Zähler ist in Ordnung. Aber der Nenner wird zu groß. Nach dem OK springt die Meldung entsprechend zur MsgBox für den NennerFehler. So weit gut. Der Haken ist, wenn Sie jetzt einen ZählerFehler machen, erscheint zwar korrekt der richtige Text, die richtige Meldung, aber nach dem OK, erscheint auch noch ein NennerFehler. Und zwar deswegen weil von hier aus einfach eine Zeile nach der nächsten abgearbeitet wird und dann geht es hier weiter. Ich muss also auch hier einen Stopp einbauen. Das ginge zum Beispiel mit Exit Sub, wenn ich sage, oh, kann ich leider nichts retten, da müssen wir hier ganz aus der Prozedur. Oder, das ist immer die bessere Lösung, Sie geben dem Benutzer eine Chance, das zu beheben, indem Sie ihm sagen, gib doch einfach dasselbe nochmal ein. Kurz gesagt, Resume. Und auch hier Resume. Das bedeutet, spring in die Zeile, wo der Fehler aufgetreten ist, das weiß der Code, und führe die einfach nochmal aus. Wenn also hier ein Fehler aufgetreten ist, springt er in die MsgBox und mit Resume springt er wieder in die Zeile und bietet dem Benutzer die Chance, den Zähler nochmal einzugeben. Viel, viel praktischer und netter. Also mit F5. Ich mache mal mit Absicht den ersten noch richtig, den Zähler. Und jetzt den Nenner, viel zu große Zahl. Kommt also nach dem OK die Meldung: Überlauf. Und dann werde ich nochmal nach dem Nenner gefragt. Und kann das jetzt entweder endlos falsch machen oder doch wieder richtig. Also mit Resume springen Sie in die Zeile, die den Fehler ausgelöst hat, wenn er denn behebbar ist. Und da kommen wir jetzt in die dritte Variante. Hier gibt es noch einen möglichen Fehler, den DivisionsFehler. Ich lasse die Zeile erstmal kommentiert, um Ihnen zu zeigen, warum der ein Problem ist. Der Zähler ist in Ordnung. Und OK. Jetzt kommt der NennerFehler, eine 0. Und die sorgt dafür, dass nach dem OK ein neuer Fehler gemeldet wird. Ein NennerFehler. Und nach dem OK kommt der immer wieder. Ewig und drei Tage. Sie können auf der Tastatur jetzt Strg+Pause drücken; Pause liegt irgendwo ganz rechts oben, Da steht vielleicht auch Strg+Untbr; um hier in die Codeunterbrechung zu kommen und jetzt zu Beenden. Was nämlich passiert ist: Hier war alles in Ordnung. Sie haben eine 0 eingegeben und der Nenner ließ sich speichern. Hier hingegen ist ein Fehler aufgetaucht, weil Division durch 0 nicht zulässig ist. Die MsgBox wird angezeigt und mit Resume geht er nicht etwa hier oben hin, sondern hierhin und wiederholt immer wieder das Teilen durch 0 und Sie kriegen leider keine Chance, den Nenner neu einzugeben. Deswegen brauche ich hier getrennt einen eigenen DivisionsFehler, der nichts anderes macht, als an eine andere Stelle zu springen. Der DivisionsFehler, den muss ich hier auch nochmal nennen; bedeutet nämlich, Sie wollen genau nicht an die Fehler auslösende Stelle springen, sondern an einer andere Stelle. Die muss ich erstmal markieren. Auch hier kommt noch ein Label rein. Und die nenne ich mal einfach NennerNeu, muss einen Doppelpunkt kriegen. Und schreibe jetzt hier unten Resume NennerNeu. Das bedeutet, wenn diese Meldung vorbei ist, springt er an die Stelle mit diesem Label. GoTo und Resume sind sich sehr ähnlich, nur das Resume macht wieder die Fehlerbehandlung frei, räumt sozusagen auf. Dann springt er hierhin, statt in die Fehler auslösende Zeile, in die Zeile, wo Sie den Nenner neu eingeben können, Also neuer Versuch. Mit F5. Der Zähler ist in Ordnung. Und OK. Der Nenner teilt jetzt durch 0, das ist für die Integer-Zuweisung in Ordnung, aber löst anschließend den DivisionsFehler aus und springt nach dem OK wieder in die Eingabe des Nenners. Ich kann es jetzt also beheben und hier wieder eine brauchbare Zahl eingeben. Dann komme ich wieder heil durch. Das Ergebnis hier, die anderen waren noch nicht gelöscht, ist auch in Ordnung. Aber, nur mal so für die Größenordnung, gucken Sie mal an, wie viel der Code jetzt vergrößert worden ist. 3 ursprüngliche Code-Zeilen. Diese, diese, und diese. Und jetzt haben wir, das kann man da oben sehen, das ist ungefähr die 4. Zeile, meinetwegen rechnen wir auch da die 6.. Bis Zeile 26. Wir habe also mal eben aus 3 Zeilen 20 Zeilen gemacht, um im Grunde nur zwei bescheidene Fehler zu beheben, oder wenigstens versuchen zu beheben. Das ist ein völliges Missverhältnis zwischen Aufwand und Erfolg. Mickrigste Fehler in minimalstem Code blasen diesen gigantisch auf und das ist einer der Kritikpunkte an der GoTo-Programmierung. Der Code springt zur Laufzeit wild hin und her. Von hier nach da, dann wieder zurück. Oder wenn der Fehler hier auftritt, nach da unten, da, und dann nach da oben zurück. Das versteht kein Mensch mehr hinterher. Ist unpflegbar. Also so sieht die offizielle Fehlerbehandlung aus. Richtig glücklich bin ich damit nicht.

Excel 2013 VBA für Profis

Nutzen Sie die Möglichkeiten der Programmiersprache VBA in Excel 2013, um eigene Dialoge zu erstellen, auf andere Arbeitsmappen zuzugreifen und wichtige Funktionen einzusetzen.

4 Std. 59 min (53 Videos)
Derzeit sind keine Feedbacks vorhanden...
 

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!