¿Por qué los bloques vacíos son una mala idea? [cerrado]

Acabo de ver una pregunta sobre try-catch , ¿qué personas (incluido Jon Skeet) dicen que los bloques de captura vacíos son una muy mala idea? ¿Por qué esto? ¿No hay una situación en la que una captura vacía no sea una decisión de diseño incorrecta?

Quiero decir, por ejemplo, a veces quieres obtener información adicional de algún lugar (servicio web, base de datos) y realmente no te importa si obtendrás esta información o no. Así que intenta obtenerlo, y si algo sucede, está bien, solo agregaré un "catch (Excepción ignorada) {}" y eso es todo

Por lo general, el try-catch vacío es una mala idea porque está tragando silenciosamente una condición de error y luego continúa la ejecución. Ocasionalmente, esto puede ser lo correcto, pero a menudo es una señal de que un desarrollador vio una excepción, no sabía qué hacer al respecto y, por lo tanto, usó una captura vacía para silenciar el problema.

Es el equivalente de programación de poner cinta negra sobre una luz de advertencia del motor.

Creo que la forma en que maneja las excepciones depende de la capa de software en la que esté trabajando: Excepciones en la selva tropical .

Son una mala idea en general porque es una condición verdaderamente rara en la que una falla (condición excepcional, más genérica) se cumple adecuadamente sin respuesta alguna. Además de eso, los catchbloques vacíos son una herramienta común utilizada por las personas que usan el motor de excepción para la verificación de errores que deberían estar haciendo de manera preventiva.

Decir que siempre es malo no es cierto ... eso es verdad de muy poco. Puede haber circunstancias en las que no le importa que haya un error o que la presencia del error de alguna manera indique que no puede hacer nada al respecto de todos modos (por ejemplo, al escribir un error anterior en un archivo de registro de texto y obtienes un IOException, lo que significa que no podrías escribir el nuevo error de todos modos).

No exageraría las cosas hasta decir que quien usa bloques de captura vacíos es un mal programador y no sabe lo que está haciendo ...

Utilizo bloques vacíos si es necesario. A veces, el programador de la biblioteca que estoy consumiendo no sabe lo que está haciendo y arroja excepciones incluso en situaciones en las que nadie lo necesita.

Por ejemplo, considere alguna biblioteca de servidor http, no me importaría menos si el servidor arroja una excepción porque el cliente se ha desconectado y index.htmlno se pudo enviar.

Hay casos raros en los que puede justificarse. En Python a menudo ves este tipo de construcción:

try:
    result = foo()
except ValueError:
    result = None

Por lo tanto, podría estar bien (dependiendo de su aplicación) hacer:

result = bar()
if result == None:
    try:
        result = foo()
    except ValueError:
        pass # Python pass is equivalent to { } in curly-brace languages
 # Now result == None if bar() returned None *and* foo() failed

En un proyecto reciente de .NET, tuve que escribir código para enumerar las DLL de complementos para encontrar clases que implementaran una interfaz determinada. El bit de código relevante (en VB.NET, lo siento) es:

    For Each dllFile As String In dllFiles
        Try
            ' Try to load the DLL as a .NET Assembly
            Dim dll As Assembly = Assembly.LoadFile(dllFile)
            ' Loop through the classes in the DLL
            For Each cls As Type In dll.GetExportedTypes()
                ' Does this class implement the interface?
                If interfaceType.IsAssignableFrom(cls) Then

                    ' ... more code here ...

                End If
            Next
        Catch ex As Exception
            ' Unable to load the Assembly or enumerate types -- just ignore
        End Try
    Next

Aunque incluso en este caso, admitiría que registrar el fallo en algún lugar probablemente sería una mejora.

Los bloques de captura vacíos generalmente se colocan porque el codificador realmente no sabe lo que está haciendo. En mi organización, un bloque de captura vacío debe incluir un comentario sobre por qué no hacer nada con la excepción es una buena idea.

En una nota relacionada, la mayoría de la gente no sabe que un bloque try {} puede seguirse con un catch {} o finalmente {}, solo se requiere uno.

Solo se deben lanzar excepciones si realmente hay una excepción: algo que está sucediendo más allá de la norma. Un bloque de captura vacío básicamente dice "algo malo está sucediendo, pero simplemente no me importa". Esta es una mala idea.

Si no desea manejar la excepción, deje que se propague hacia arriba hasta que llegue a algún código que pueda manejarlo. Si nada puede manejar la excepción, debería quitar la aplicación.

Creo que está bien si detecta un tipo de excepción particular del cual sabe que solo se generará por una razón en particular , y espera esa excepción y realmente no necesita hacer nada al respecto.

Pero incluso en ese caso, un mensaje de depuración podría estar en orden.

Por Josh Bloch - Artículo 65: No ignore las excepciones de Java efectivo :

1. Un bloque de captura vacío anula el propósito de las excepciones.
2. Como mínimo, el bloque catch debe contener un comentario que explique por qué es apropiado ignorar la excepción.

Un bloque de captura vacío básicamente dice "No quiero saber qué errores se lanzan, solo voy a ignorarlos".

Es similar a los VB6 On Error Resume Next, excepto que se omitirá cualquier cosa en el bloque de prueba después de lanzar la excepción.

Lo que no ayuda cuando algo se rompe.

Esto va de la mano con "No use excepciones para controlar el flujo del programa" y "Solo use excepciones para circunstancias excepcionales". Si se hacen, las excepciones solo deberían ocurrir cuando hay un problema. Y si hay un problema, no querrás fallar en silencio. En las raras anomalías donde no es necesario manejar el problema, al menos debe registrar la excepción, en caso de que la anomalía deje de ser una anomalía. Lo único peor que fallar es fallar en silencio.

Creo que un bloque catch completamente vacío es una mala idea porque no hay forma de inferir que ignorar la excepción fue el comportamiento previsto del código. No es necesariamente malo tragar una excepción y devolver falso o nulo o algún otro valor en algunos casos. El marco .net tiene muchos métodos de "prueba" que se comportan de esta manera. Como regla general si se traga una excepción, agregue un comentario y una declaración de registro si la aplicación admite el registro.

Porque si se lanza una excepción , nunca la verás (fallar en silencio es la peor opción posible) obtendrás un comportamiento erróneo y no tendrás idea de dónde está sucediendo. ¡Al menos pon un mensaje de registro allí! ¡Incluso si es algo que 'nunca puede suceder'!

Los bloques de captura vacíos son una indicación de que un programador no sabe qué hacer con una excepción. Están suprimiendo la excepción de posiblemente surgir y ser manejado correctamente por otro bloque de prueba. Siempre trate de hacer algo con la excepción que está atrapando.

Lo más molesto con las declaraciones catch vacías es cuando algún otro programador lo hizo. Lo que quiero decir es que cuando necesita depurar el código de otra persona, cualquier declaración catch vacía hace que dicha tarea sea más difícil de lo que debe ser. En mi humilde opinión, las declaraciones catch siempre deben mostrar algún tipo de mensaje de error, incluso si el error no se maneja, al menos debería detectarlo (alt. Solo en modo de depuración)

Probablemente nunca sea lo correcto porque estás pasando silenciosamente todas las excepciones posibles. Si hay una excepción específica que está esperando, entonces debe probarla, volver a lanzarla si no es su excepción.

try
{
    // Do some processing.
}
catch (FileNotFound fnf)
{
    HandleFileNotFound(fnf);
}
catch (Exception e)
{
    if (!IsGenericButExpected(e))
        throw;
}

public bool IsGenericButExpected(Exception exception)
{
    var expected = false;
    if (exception.Message == "some expected message")
    {
        // Handle gracefully ... ie. log or something.
        expected = true;
    }

    return expected;
}

En general, solo debe detectar las excepciones que realmente puede manejar. Eso significa ser lo más específico posible al detectar excepciones. Capturar todas las excepciones rara vez es una buena idea e ignorar todas las excepciones es casi siempre una muy mala idea.

Solo puedo pensar en algunos casos en los que un bloque de captura vacío tiene un propósito significativo. Si cualquiera que sea la excepción específica, se está "manejando" simplemente volviendo a intentar la acción, no habría necesidad de hacer nada en el bloque de captura. Sin embargo, aún sería una buena idea registrar el hecho de que ocurrió la excepción.

Otro ejemplo: CLR 2.0 cambió la forma en que se tratan las excepciones no controladas en el subproceso finalizador. Antes de 2.0, el proceso podía sobrevivir a este escenario. En el CLR actual, el proceso finaliza en caso de una excepción no controlada en el subproceso finalizador.

Tenga en cuenta que solo debe implementar un finalizador si realmente lo necesita e incluso entonces debe hacer lo menos posible en el finalizador. Pero si cualquier trabajo que debe hacer su finalizador podría arrojar una excepción, debe elegir entre el menor de los dos males. ¿Desea cerrar la aplicación debido a la excepción no controlada? ¿O quieres proceder en un estado más o menos indefinido? Al menos en teoría, este último puede ser el menor de dos males en algunos casos. En esos casos, el bloque catch vacío evitaría que el proceso se terminara.

Quiero decir, por ejemplo, a veces quieres obtener información adicional de algún lugar (servicio web, base de datos) y realmente no te importa si obtendrás esta información o no. Así que intenta obtenerlo, y si algo sucede, está bien, solo agregaré un "catch (Excepción ignorada) {}" y eso es todo

Entonces, siguiendo su ejemplo, es una mala idea en ese caso porque está captando e ignorando todas las excepciones. Si solo estuvieras atrapando EInfoFromIrrelevantSourceNotAvailablee ignorando eso, estaría bien, pero no lo estás. También estás ignorando ENetworkIsDown, lo que puede o no ser importante. Estás ignorando ENetworkCardHasMeltedyEFPUHasDecidedThatOnePlusOneIsSeventeen , lo que es casi seguro, importante.

Un bloque catch vacío no es un problema si está configurado para capturar solo (e ignorar) excepciones de ciertos tipos que usted sabe que no son importantes. Las situaciones en las que es una buena idea suprimir e ignorar silenciosamente todas las excepciones, sin detenerse a examinarlas primero para ver si son esperadas / normales / irrelevantes o no, son extremadamente raras.

Hay situaciones en las que podría usarlos, pero deberían ser muy poco frecuentes. Las situaciones en las que podría usar una incluyen:

• registro de excepciones; dependiendo del contexto, es posible que desee publicar una excepción no controlada o un mensaje.

• situaciones técnicas en bucle, como procesamiento o procesamiento de sonido o una devolución de llamada de cuadro de lista, donde el comportamiento en sí mismo demostrará el problema, lanzar una excepción solo se interpondrá en el camino, y registrar la excepción probablemente solo dará como resultado miles de mensajes "fallidos a XXX" .

• programas que no pueden fallar, aunque al menos deberían estar registrando algo.

Para la mayoría de las aplicaciones winforms, he descubierto que es suficiente tener una única declaración de prueba para cada entrada del usuario. Utilizo los siguientes métodos: (AlertBox es solo un rápido MessageBox.Show wrapper)

  public static bool TryAction(Action pAction)
  {
     try { pAction(); return true; }
     catch (Exception exception)
     {
        LogException(exception);
        return false;
     }
  }

  public static bool TryActionQuietly(Action pAction)
  {
     try { pAction(); return true; }
     catch(Exception exception)
     {
        LogExceptionQuietly(exception);
        return false;
     }
  }

  public static void LogException(Exception pException)
  {
     try
     {
        AlertBox(pException, true);
        LogExceptionQuietly(pException);
     }
     catch { }
  }

  public static void LogExceptionQuietly(Exception pException)
  {
     try { Debug.WriteLine("Exception: {0}", pException.Message); } catch { }
  }

Entonces cada controlador de eventos puede hacer algo como:

  private void mCloseToolStripMenuItem_Click(object pSender, EventArgs pEventArgs)
  {
     EditorDefines.TryAction(Dispose);
  }

o

  private void MainForm_Paint(object pSender, PaintEventArgs pEventArgs)
  {
     EditorDefines.TryActionQuietly(() => Render(pEventArgs));
  }

Teóricamente, podría tener TryActionSilently, que podría ser mejor para realizar llamadas de modo que una excepción no genere una cantidad interminable de mensajes.

Si no sabe qué hacer en el bloque catch, puede registrar esta excepción, pero no dejarla en blanco.

        try
        {
            string a = "125";
            int b = int.Parse(a);
        }
        catch (Exception ex)
        {
            Log.LogError(ex);
        }

Nunca debe tener un bloque de captura vacío. Es como esconder un error que conoces. Como mínimo, debe escribir una excepción a un archivo de registro para revisar más adelante si tiene poco tiempo.