Odpowiedź.

W Visual Basic .NET można tworzyć własne typy wyjątków, aby bardziej wyraźnie wskazywać na specyficzne błędy, które wystąpiły w aplikacji. W tym celu należy dziedziczyć nową klasę od System.Exception (lub jednego z jego potomków) i, w razie potrzeby, dodawać nowe właściwości do przekazywania dodatkowych informacji.

Custom Exceptions pozwalają uczynić kod bardziej czytelnym i łatwiejszym do utrzymania, zwłaszcza jeśli potrzebujesz specyficznej obsługi dla określonych scenariuszy biznesowych.

Przykład:

Public Class InvalidUserNameException
    Inherits ApplicationException
    Public Sub New(message As String)
        MyBase.New(message)
    End Sub
End Class

' Użycie:
Sub ValidateUserName(userName As String)
    If userName = "" Then
        Throw New InvalidUserNameException("Nazwa użytkownika nie może być pusta")
    End If
End Sub

Pytanie podchwytliwe.

Pytanie: „Czy można po prostu wyrzucić ciąg za pomocą Throw "Błąd" w Visual Basic i czy Try...Catch to obsłuży?”

Odpowiedź: Nie, nie można tego zrobić. Operator Throw wymaga obiektu typu Exception. Próba wyrzucenia ciągu (Throw "err") spowoduje błąd kompilacji. Zawsze trzeba tworzyć nowy egzemplarz klasy Exception lub jej potomka.

Przykład błędnego kodu:

' To spowoduje błąd!
Throw "Błąd!"

Przykład poprawnego kodu:

Throw New Exception("Błąd!")

Przykłady rzeczywistych błędów z powodu braku znajomości szczegółów tematu.

---

Historia:

Na dużym projekcie jeden z programistów wyrzucał wyjątki za pomocą Throw "Nieprawidłowe dane!". To prowadziło do błędów kompilacji na produkcji, ponieważ kod nie przeszedł statycznej kontroli. Brak prawidłowej obsługi wyjątków spowolnił wydanie o tydzień — trzeba było szukać i przepisywać wszystkie przypadki użycia throw ze stringami w kodzie.

---

Historia:

Zespół tworzył niestandardowe wyjątki, nie dodając konstruktora z parametrem InnerException. Podczas diagnozowania złożonych błędów tracił się stos wywołań z powodu niemożności „zagnieżdżenia” oryginalnego wyjątku. W rezultacie trudno było znaleźć pierwotną przyczynę wystąpienia awarii.

---

Historia:

W aplikacji multimedialnej niestandardowy wyjątek był używany zbyt często i niezgodnie z przeznaczeniem (na przykład przy każdym nieprawidłowym wprowadzeniu danych). W rezultacie wydajność systemu spadła — generowanie wyjątków jest operacyjnie kosztowne. Po przeglądzie część takich wyjątków została zastąpiona zwykłymi kontrolami warunków.