Respuesta.

En Visual Basic .NET se pueden crear tipos de excepciones propias para indicar de manera más clara errores específicos que ocurren en la aplicación. Para ello, es necesario heredar una nueva clase de System.Exception (o de uno de sus descendientes) y, si es necesario, agregar nuevas propiedades para transmitir información adicional.

Las Custom Exceptions permiten que el código sea más legible y mantenible, especialmente si se necesita un manejo específico para determinados escenarios de negocio.

Ejemplo:

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

' Uso:
Sub ValidateUserName(userName As String)
    If userName = "" Then
        Throw New InvalidUserNameException("El nombre de usuario no puede estar vacío")
    End If
End Sub

Pregunta trampa.

Pregunta: "¿Se puede simplemente lanzar una cadena usando Throw "Error" en Visual Basic, y lo manejará Try...Catch?"

Respuesta: No, no se puede hacer eso. El operador Throw requiere un objeto de tipo Exception. Intentar lanzar una cadena (Throw "err") causará un error de compilación. Siempre se debe crear una nueva instancia de la clase Exception o de su descendiente.

Ejemplo de código incorrecto:

' ¡Esto causará un error!
Throw "¡Error!"

Ejemplo de código correcto:

Throw New Exception("¡Error!")

Ejemplos de errores reales debido a la falta de conocimiento sobre el tema.

---

Historia:

En un gran proyecto, uno de los desarrolladores lanzaba excepciones usando Throw "Datos incorrectos!". Esto provocó errores de compilación en producción, ya que el código no pasó la verificación estática. La falta de un manejo adecuado de excepciones retrasó el lanzamiento una semana; fue necesario buscar y reescribir todos los casos de uso de throw con cadenas en el código.

---

Historia:

El equipo creaba excepciones personalizadas sin agregar un constructor con el parámetro InnerException. Al diagnosticar errores complejos, se perdía la pila de llamadas debido a la imposibilidad de "anidar" la excepción original. Como resultado, fue difícil encontrar la causa inicial del fallo.

---

Historia:

En una aplicación multimedia, se usaba la excepción personalizada con demasiada frecuencia y fuera de su propósito (por ejemplo, en cada entrada de datos incorrecta). Como resultado, el rendimiento del sistema disminuyó, ya que la generación de excepciones tiene un costo operativo elevado. Tras una revisión, se reemplazaron algunas de estas excepciones por comprobaciones de condiciones normales.