ProgrammazioneSviluppatore VB.NET

Come implementare la gestione delle eccezioni personalizzate (Custom Exceptions) in Visual Basic e in quali casi è davvero necessaria?

Supera i colloqui con l'assistente IA Hintsage

Risposta.

In Visual Basic .NET è possibile creare propri tipi di eccezioni per indicare in modo più chiaro errori specifici che si sono verificati nell'applicazione. Per fare ciò, è necessario ereditare una nuova classe da System.Exception (o da una sua sottoclasse) e, se necessario, aggiungere nuove proprietà per fornire informazioni aggiuntive.

Le Custom Exceptions consentono di rendere il codice più leggibile e manutenibile, soprattutto se è necessaria una gestione specifica per determinati scenari aziendali.

Esempio:

Public Class InvalidUserNameException Inherits ApplicationException Public Sub New(message As String) MyBase.New(message) End Sub End Class ' Utilizzo: Sub ValidateUserName(userName As String) If userName = "" Then Throw New InvalidUserNameException("Il nome utente non può essere vuoto") End If End Sub

Domanda trucco.

Domanda: «È possibile semplicemente lanciare una stringa usando Throw "Errore" in Visual Basic, e gestirà questo Try...Catch?»

Risposta: No, non si può fare. L'operatore Throw richiede un oggetto di tipo Exception. Tentare di lanciare una stringa (Throw "err") porterà a un errore di compilazione. È necessario sempre creare una nuova istanza della classe Exception o di una sua sottoclasse.

Esempio di codice errato:

' Questo genererà un errore! Throw "Errore!"

Esempio di codice corretto:

Throw New Exception("Errore!")

Esempi di errori reali dovuti all'ignoranza delle sottigliezze dell'argomento.


Storia:

In un grande progetto, uno degli sviluppatori lanciava eccezioni usando Throw "Dati non validi!". Questo portava a errori di compilazione in produzione, poiché il codice non aveva superato il controllo statico. La mancanza di una corretta gestione delle eccezioni ha ritardato il rilascio di una settimana — è stato necessario cercare e riscrivere tutti i casi di utilizzo di throw con stringhe nel codice.


Storia:

Il team creava eccezioni personalizzate senza aggiungere un costruttore con il parametro InnerException. Durante la diagnosi di errori complessi, si perdeva lo stack delle chiamate a causa dell'impossibilità di "annidare" l'eccezione originale. Di conseguenza, era difficile trovare la causa iniziale del guasto.


Storia:

In un'applicazione media, l'eccezione personalizzata è stata utilizzata troppo frequentemente e non per lo scopo previsto (ad esempio, in caso di ogni input non valido). Di conseguenza, le prestazioni del sistema sono diminuite — poiché la generazione di eccezioni è operativamente costosa. Dopo una revisione, alcune di queste eccezioni sono state sostituite con semplici controlli delle condizioni.