ProgrammierungVB.NET Entwickler

Wie implementiert man die Verarbeitung von benutzerdefinierten Fehlern (Custom Exceptions) in Visual Basic und in welchen Fällen ist dies wirklich notwendig?

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

Antwort.

In Visual Basic .NET können Sie eigene Ausnahmetypen erstellen, um spezifische Fehler, die in der Anwendung aufgetreten sind, deutlicher zu kennzeichnen. Dazu müssen Sie eine neue Klasse von System.Exception (oder einer seiner Unterklassen) ableiten und bei Bedarf neue Eigenschaften hinzufügen, um zusätzliche Informationen zu übermitteln.

Custom Exceptions ermöglichen es, den Code lesbarer und wartbarer zu gestalten, insbesondere wenn spezifische Behandlungen für bestimmte Geschäftsszenarien erforderlich sind.

Beispiel:

Public Class InvalidUserNameException Inherits ApplicationException Public Sub New(message As String) MyBase.New(message) End Sub End Class ' Verwendung: Sub ValidateUserName(userName As String) If userName = "" Then Throw New InvalidUserNameException("Der Benutzername darf nicht leer sein") End If End Sub

Fangfrage.

Frage: „Kann man einfach eine Zeichenfolge mit Throw "Fehler" in Visual Basic auslösen, und wird dies von Try...Catch verarbeitet?“

Antwort: Nein, das geht nicht. Der Operator Throw verlangt ein Objekt vom Typ Exception. Der Versuch, eine Zeichenfolge auszulösen (Throw "err"), führt zu einem Kompilierungsfehler. Man muss immer eine neue Instanz der Klasse Exception oder einer ihrer Unterklassen erstellen.

Beispiel für fehlerhaften Code:

' Das wird einen Fehler auslösen! Throw "Fehler!"

Beispiel für korrekten Code:

Throw New Exception("Fehler!")

Beispiele für echte Fehler aufgrund von Unkenntnis der Details des Themas.


Geschichte:

In einem großen Projekt löste einer der Entwickler Ausnahmen mit Throw "Ungültige Daten!" aus. Das führte zu Kompilierungsfehlern in der Produktion, da der Code die statische Überprüfung nicht bestanden hatte. Das Fehlen einer ordnungsgemäßen Behandlung von Ausnahmen verzögerte die Veröffentlichung um eine Woche — es mussten alle Fälle von throw mit Zeichenfolgen im Code gesucht und umgeschrieben werden.


Geschichte:

Das Team erstellte benutzerdefinierte Ausnahmen, ohne einen Konstruktor mit dem Parameter InnerException hinzuzufügen. Bei der Diagnose komplexer Fehler ging der Aufrufstack aufgrund der Unfähigkeit, die ursprüngliche Ausnahme „einzuschachteln“, verloren. Infolgedessen war es schwierig, die ursprüngliche Ursache des Fehlers zu finden.


Geschichte:

In der Medienanwendung wurden benutzerdefinierte Ausnahmen zu häufig und nicht bestimmungsgemäß verwendet (z. B. bei jeder ungültigen Dateneingabe). Infolgedessen sank die Systemleistung — denn die Generierung von Ausnahmen ist betrieblich aufwendig. Nach der Überprüfung wurden einige dieser Ausnahmen durch normale bedingte Überprüfungen ersetzt.