ProgrammierungVB.NET Entwickler, Backend Entwickler

Wie wird die Ausnahmebehandlung und das Weiterwerfen (rethrow) von Ausnahmen in Visual Basic umgesetzt? Welche Feinheiten gibt es zwischen dem Operator Throw und Throw ex, und welche Gefahren birgt das falsche Wiederwerfen von Ausnahmen?

Bestehen Sie Vorstellungsgespräche mit dem Hintsage-KI-Assistenten

Antwort

In Visual Basic wird die Ausnahmebehandlung mittels des Blocks Try...Catch...Finally umgesetzt. Um eine Ausnahme nach ihrer Abfangung weiterzugeben – d.h. sie durch den Aufrufstapel weiterzuleiten – wird der Operator Throw oder Throw ex verwendet.

Unterschiede:

  • Throw (ohne Parameter) wirft die aktuelle Ausnahme erneut und bewahrt den ursprünglichen Aufrufstapel (Call Stack).
  • Throw ex wirft das Ausnahmeobjekt, setzt jedoch den Aufrufstapel zurück – die Information über den tatsächlichen Ort, an dem das Problem auftrat, geht verloren.

Es wird empfohlen, Throw ohne Parameter für ein korrektes Weiterwerfen von Ausnahmen zu verwenden, wenn sie nicht modifiziert wurden.

Beispiel für korrektes Weiterwerfen:

Try DangerousOperation() Catch ex As Exception ' Protokollierung... Throw ' Aufrufstapel wird bewahrt End Try

Falsche Methode:

Try DangerousOperation() Catch ex As Exception Throw ex ' Aufrufstapel zurückgesetzt, Diagnose erschwert End Try

Fangfrage

Was passiert mit dem Aufrufsstapel, wenn Sie Throw ex anstelle von Throw verwenden?

Bei der Verwendung von Throw ohne Parameter bleibt der ursprüngliche Aufrufstapel – der, an dem die Ausnahme aufgetreten ist – erhalten. Bei der Verwendung von Throw ex beginnt der Stapel mit der aktuellen Zeile, und der ursprüngliche Ort des Auftretens geht verloren. Dies erschwert das Debugging, da Sie nicht sehen, an welchem Teil des Codes das Problem aufgetreten ist.

Beispiele für reale Fehler aufgrund von Unkenntnis der Feinheiten des Themas


Geschichte

In einem großen Bankprojekt verwendeten die Entwickler Throw ex, um logische Fehler auszulösen. Bei der Analyse der Protokolle stellte sich heraus, dass es unmöglich war, den Ort der Ausnahmen zu bestimmen, da die korrekte Nachverfolgung fehlte.


Geschichte

Innerhalb der Datenspeicherschicht wurde Throw zum Weiterwerfen von SqlException verwendet, aber in einigen Fällen ersetzte das Codeformatierungswerkzeug es automatisch durch Throw ex. Dies störte das System zur automatischen Datenextraktion aus den Protokollen und verlängerte die Reaktionszeit auf Vorfälle.


Geschichte

Der Versuch, das Objekt Exception zu modifizieren und es über Throw ohne Parameter weiterzugeben, führte dazu, dass die Änderungen nicht in den Protokollen widergespiegelt wurden – nur die explizite Erstellung eines neuen Ausnahmeobjekts unter Beibehaltung des ursprünglichen als InnerException half.