Abfangen von Exceptions

[M.Dietz]

Hallo zusammen,

Da wir von unseren Usern immer nur unzureichende Informationen über Abstürze bekommen (Nun gut, ist nicht deren Schuld, die können das nicht besser angeben), habe ich folgendes eingefügt:

        Try
            Application.Run(frmMain)
        Catch ex As Exception
            ShowInternalError("Ein Fehler ist aufgetreten. Bitte senden Sie einen Screenshot dieser Fehlermeldung an einen Entwickler:" & ex.Message & vbCrLf & vbCrLf & ex.StackTrace)
        Finally
            Windows.Forms.Cursor.Current = Cursors.Default
            ...
            session.CloseDB()
        End Try

Dies sollte eine Exceptionmeldung bringen, wie im Anhang gezeigt, was die User aber erhalten, ist eine Exception Meldung wie im anderen Anhang, was es uns Entwicklern dann wieder schwieriger macht, weil wir dann doch erst die Situation nachstellen müssen, um die komplette Meldung zu sehen, was nicht immer möglich ist, oder "blind" Exceptions abfangen müssen (was von meinem Chef definitiv nicht gewünscht wird, er möchte lieber das Programm unkontrolliert abstürzen lassen, als dem Prozessor/Speicher die Belastung durch eine Fehlerbehandlung zuzumuten, aber was soll ich da sagen, er ist mein Vorgesetzter und so werden mögliche Fehlerquellen halt erst behoben, wenn sie mindestens einmal aufgetreten sind )

Ist das irgendeine Eigenschaft einer Runtime, dass sie die Fehler selbst abfängt und anzeigt, anstatt darauf zu warten, dass das Programm ein paar Ebenen höher es selbst macht? Oder liegt das an irgendwelchen Projekteinstellungen, die ich nur nicht als solche erkenne? Wenn ich das Programm debugge bekomme ich nämlich meinen Abfangpunkt und meine eigene Fehlermeldung!

Mal sehen, vielleicht weiß ja jemand Bescheid...

Gruß
Martin Dietz

[laptel]

Hallo Martin,

sag mir doch mal, wie du zu ShowInternalError kommst. Die MSDN kennt den Ausdruck gar nicht. Es gibt eine InternalErrorException-Klasse, aber die Anmerkung dazu ist: "Diese API unterstützt die .NET Framework-Infrastruktur und ist nicht für die direkte Verwendung in Code bestimmt."

Einfach wild alles abzufangen ist auch unsinnig. Da hat dein Cheffe schon recht.
So was kann durchaus auch zu einer schlechten Performance der Anwendung führen. Wichtig sind halt Operationen wie Dateihandling oder Datenbankconnects.

Falls du Visual Studio Tema System hast, dann start mal ne Codeanlyse, wenn nicht mach dich mit dem FXCop vertraut.
Beide werden dir anzeigen, dass Catch ex As Exception (welches ich eigentlich auch immer benutze) nicht gerade günstig ist. Man solle spezifizierte Fehlerbehandlungen schreiben.

Sorry, jetzt direkt zu deinem Problem kann ich keine Lösung anbieten.
Ich vermute, dass Application.Run(frmMain) eine eigene Instanz aufruft und somit nicht deine Behandlung anspricht, sondern die Standardfehlerbehandlung. Dem Inhalt nach, wird in beiden ja das gleiche angezeigt.

mfg laptel

[M.Dietz]

Sorry, dachte nicht, dass ShowInternalError relevant ist:

ShowInternalError ist eine von zwei Fehlermeldungsroutinen, die wir in einem globalen Modul definiert haben, um nicht immer sämtliche Parameter wie Fenstertitel, Buttons usw. angeben zu müssen. Es gibt ShowError, das über eine globale Variable stumm geschaltet werden kann (für Vorgänge die im Batch-Betrieb laufen) weil sie vom Programm behebbar sind oder nur protokolliert werden müssen, ohne dass der User eingreifen muss, da sie den weiteren Ablauf nicht stören, und ShowInternalError, die unbeeindruckt von globalen Variablen die Fehlermeldung ausgibt, da das Auftreten eines solchen Fehlers meist auf Programmierfehler oder Schnittstellenprobleme zurückzuführen ist, nicht automatisch behoben werden kann, und daher eine unbeaufsichtigte Fortführung des Vorgangs die Stabilität des Programms und die Konsistenz der Daten gefährden würde.

Was das "blind abfangen" angeht, da gebe ich Dir natürlich recht, alles wird auch nicht abgefangen, aber mein Chef geht da sehr blauäugig an die Sache ran "SAP erzeugt keine Exceptions" und "Die Netzwerkverbindung zum SQL-Server wird nicht zusammenbrechen", "Exceptions können nur auftreten, wenn Sie etwas falsch programmiert haben" usw. und das obwohl ich regelmäßig bei Untersuchungen auf nicht-initialisierte Variablen aus der Zeit treffe, als er den Code noch selbst gepflegt hat, weil z.B. die Schnittstelle zur Datenbank Nothing zurückgibt statt eines leeren Strings bzw. es der Schnittstelle egal war, ob ihr Nothing übergeben wird, bis sie plötzlich führende Nullen abschneiden muss, oder eine leere Zelle in Excel beim Auslesen Nothing liefert, was ich dann einer Funktion übergebe, die ohne eine Überprüfung irgendwelche Memberfunktionen aufruft, obwohl ich eigentlich davon ausgehen könnte, dass dort eine entsprechende Überprüfung stattfindet (wie z.B. in der selbstgeschriebenen Konvertierungsfunktion GetLng(String), wo zwar überprüft wird, ob nur gültige Zeichen auftauchen, eine Nullverweisprüfung aber übergangen wurde), und wenn dann wegen so etwas die ganze Applikation abstürzt, statt nur die Aktion zu unterbrechen und ggf. schon importierte Datensätz wieder zu löschen ist das einfach nur ärgerlich, aber ich glaube ich schweife ab...

Das Catch as Exception in der Hauptebene ist drin, weil alle Arten von Exceptions, die es bis dorthin schaffen die gleiche Art von Behandlung (nämlich das bloße Anzeigen mit StackTrace) erfahren sollen, und ich definitiv an der Stelle nicht unterscheiden wollte, ob es sich um einen Nullverweis, einen Timeout in der Datenbankklasse, eine nicht gefundene Datei in einem Druckaufruf, ein 'Access denied' beim Zugriff auf ein Verzeichnis oder was auch sonst handeln könnte.

Nun, wenn es am Application.Run(frmMain) liegt, muss ich diesbezüglich mal schlau machen. Danke erstmal soweit

Gruß
Martin Dietz