Respuesta.

En Visual Basic, se utilizan las construcciones On Error (VB6) y Try...Catch (VB.NET) para el manejo de errores.

• On Error GoTo <Etiqueta> — un método obsoleto de VB6 que implementa un salto a la etiqueta especificada en caso de error. No soporta anidamiento y puede llevar a un código confuso.
• Try...Catch...Finally — un método moderno (VB.NET) que permite trabajar con excepciones, ofrece la posibilidad de manejar diferentes tipos de errores en diferentes bloques Catch y asegura la ejecución de acciones finales en Finally.

Ejemplos:

VB6:

Sub OpenFile()
    On Error GoTo ErrorHandler
    Open "file.txt" For Input As #1
    ' Leer archivo
    Close #1
    Exit Sub
ErrorHandler:
    MsgBox "Error: " & Err.Description
End Sub

VB.NET:

Sub OpenFileVBNet()
    Try
        Using reader As New StreamReader("file.txt")
            Dim line As String = reader.ReadLine()
        End Using
    Catch ex As IOException
        MsgBox("Error: " & ex.Message)
    Finally
        ' Siempre se ejecuta
    End Try
End Sub

Pregunta capciosa.

Si ocurre un error en VB6 en el bloque On Error Resume Next, ¿cómo saber exactamente dónde ocurrió y cómo manejarlo correctamente?

Respuesta correcta: En el modo On Error Resume Next, el programa continúa la ejecución en la siguiente línea. Para saber si ocurrió un error, se debe comprobar el objeto Err al final de la llamada.

On Error Resume Next
' algún código
If Err.Number <> 0 Then
    MsgBox "Error: " & Err.Description
    Err.Clear
End If

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

---

Historia

Después de pasar de VB6 a VB.NET, algunos manejadores quedaron en el estilo On Error GoTo, lo que llevó a un enmascaramiento implícito de errores. Se confundió la lógica de manejo, lo que resultó en datos en la base de datos quedándose a medio procesar, y el error se descubrió solo meses después.

---

Historia

No se utilizó Err.Clear, como resultado, después de un error manejado, Err.Number se mantenía diferente de cero. En las verificaciones posteriores, el programa erróneamente pensaba que había ocurrido un nuevo error y tomaba caminos de manejo incorrectos.

---

Historia

Al refactorizar, se olvidaron de eliminar On Error Resume Next, por lo que los errores "se tragaban" y no emitían ningún mensaje. El diagnóstico de problemas tomaba horas, ya que la aplicación parecía funcionar con normalidad, pero en realidad perdía datos importantes.