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

Question

Acabo de ver una pregunta sobre try-catch , ¿qué personas (incluido Jon Skeet) dicen que los bloques vacíos son una 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 '' captura (Excepción ignorada) {} '' y eso es todo

Answer 1

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 .

Answer 2

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 bloques vacíos catch 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 es siempre 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 una IOException , lo que significa que no podrías escribir el nuevo error de todos modos).

Answer 3

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 catch vacíos si es necesario. A veces, el programador de la biblioteca que estoy consumiendo no sabe lo que está haciendo y lanza excepciones incluso en situaciones en las que nadie lo necesita.

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

Answer 4

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, puede 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 la falla en algún lugar probablemente sería una mejora.

Answer 5

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 catch 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 se puede seguir un bloque try {} con un catch {} o finalmente {}, solo se requiere uno.

Answer 6

Las excepciones solo se deben lanzar 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 manejarla. Si nada puede manejar la excepción, debería cerrar la aplicación.

Answer 7

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

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

Answer 8

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.

Answer 9

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

Es similar al de VB6 al reanudar el error a continuación , 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.

Answer 10

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 debería 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.

Answer 11

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 framework .net tiene muchos "try" métodos 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.

Answer 12

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'!

Answer 13

Los bloques catch 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.

Answer 14

Creo que 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 tal 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)

Answer 15

Probablemente nunca sea lo correcto porque estás pasando silenciosamente cada posible excepción. 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;
}

Answer 16

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 se me ocurren algunas instancias en las que un bloque catch vacío tiene un propósito significativo. Si cualquiera que sea la excepción específica, está capturando se maneja " 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 su finalizador debe hacer 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.

Answer 17

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 '' captura (Excepción ignorada) {} '' y eso es todo

Entonces, siguiendo su ejemplo, es una mala idea en ese caso porque está captando e ignorando todas excepciones. Si solo capturara EInfoFromIrrelevantSourceNotAvailable y lo ignora, estaría bien, pero no lo está. También está ignorando ENetworkIsDown , que puede o no ser importante. Estás ignorando ENetworkCardHasMelted y EFPUHasDecidedThatOnePlusOneIsSeventeen , que casi con toda seguridad son importantes.

Un bloque catch vacío no es un problema si está configurado para capturar (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 excepciones, sin detenerse a examinarlas primero para ver si son esperadas / normales / irrelevantes o no, son extremadamente raras.

Answer 18

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 renderizado o procesamiento de sonido o una devolución de llamada de cuadro de lista, donde el comportamiento en sí demostrará el problema, lanzar una excepción solo se interpondrá en el camino, y el registro de la excepción probablemente solo dará como resultado miles de " falló a XXX " mensajes.

• 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 contenedor rápido de MessageBox.Show)

  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.

Answer 19

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.

Answer 20

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);
        }