c# - texto - ¿Por qué no puedo escribir solo un intento sin captura o finalmente?

no puedo escribir en whatsapp solo audio

Question

A veces hago esto y he visto a otros hacerlo también:

VB:

Try
    DontWannaCatchIt()
Catch
End Try

DO#:

try 
{ 
    DontWannaCatchIt();
} 
catch {}

Sé que debería detectar todas las excepciones importantes que estoy esperando y hacer algo al respecto, pero a veces no es importante, ¿o estoy haciendo algo mal?

¿Es incorrecto este uso del bloque try , y el requisito de al menos una catch o, finally bloquear una indicación de ello?

Actualizar:

Ahora entiendo la razón de esto, y es que al menos debo comentar sobre el bloque catch vacío para que otros entiendan por qué está vacío. También debería capturar sólo las excepciones que estoy esperando.

Por suerte para mí, estoy codificando en VB para poder escribirlo en una sola captura:

Catch ex As Exception When TypeOf ex Is IOException _
                    OrElse TypeOf ex Is ArgumentException _
                    OrElse TypeOf ex Is NotSupportedException _
                    OrElse TypeOf ex Is SecurityException _
                    OrElse TypeOf ex Is UnauthorizedAccessException
    ''I don''t actually care.
End Try

Answer 1

¿Y si solo escribes código con try?

try
{
   int j =0;
   5/j;
}

esto equivaldría a escribir

 int j =0;
   5/j;

Por lo tanto, escribir try no tiene ningún sentido, solo aumenta el número de líneas.

Ahora, si escribe try con captura vacía o, finalmente, está indicando explícitamente que el tiempo de ejecución se comporte de manera diferente.

así que ''por qué creo que el bloque de prueba vacío no es posible.

Answer 2

Además, si no tiene que hacer algo acerca de un error, tal vez debería especificar qué tipo de excepción debe ignorar el programa.

Si tiene que ignorar todas las excepciones, no puedo ver por qué no puede usar try / catch de esta manera.

Answer 3

Existe un error, ha sido lanzado, y necesita ir a algún lugar. El flujo de código normal ha sido abortado y el ventilador necesita ser limpiado.

Ningún bloque catch = estado indeterminado. ¿Dónde debería ir el código? ¿Qué debería hacer?

Un bloque de captura vacío = error manejado ignorándolo.

Nota: VBA tiene un vil "On Error Continue" ...

Answer 4

La razón por la que he oído es que si su intento falla por CUALQUIER razón, es muy preferible otorgarle el control de la respuesta de error al control de Framework, es decir, la pantalla amarilla o el error 500.

Answer 5

No es fácil hacerlo porque la mayoría de los desarrolladores lo consideran una mala práctica.

¿Qué DontWannaCatchIt() si alguien agrega luego una llamada de método al cuerpo de DontWannaCatchIt() que arroja una excepción que vale la pena atrapar, pero que su bloque de captura vacía la traga? ¿Qué sucede si hay algunas excepciones que realmente querría atrapar, pero no se dio cuenta en ese momento?

Si es absolutamente necesario hacerlo, trate de ser lo más específico posible con el tipo de excepción que va a detectar. Si no, quizás registrar la excepción sea una opción.

Answer 6

No, no debes atrapar todas las excepciones importantes. Está bien detectar e ignorar las excepciones que no le interesan, como un error de E / S si no hay nada que pueda hacer para corregirlo y no quiere molestarse en informar al usuario.

Pero debe permitir que se propaguen excepciones como Exception y OutOfMemoryException . O, más comúnmente, NullReferenceException . Estas excepciones son generalmente errores que no anticipó, no puede recuperar, no debe recuperar y no debe suprimirse.

Si desea ignorar una excepción, es bueno escribir explícitamente un bloque catch vacío en el código para esa excepción en particular. Esto deja en claro exactamente qué excepciones estás ignorando. Ignorar las excepciones de manera muy correcta es un procedimiento de inclusión, no uno de exclusión. Tener una función de "ignorar todas las excepciones" que luego puede ser anulada para no ignorar tipos específicos sería una característica de lenguaje muy mala.

¿Cómo sabe qué tipos de excepciones son importantes y no deben detectarse? ¿Qué pasa si hay excepciones que no conoces? ¿Cómo sabes que no acabarás eliminando errores importantes con los que no estás familiarizado?

try
{
}
// I don''t care about exceptions.
catch
{
}
// Okay, well, except for system errors like out of memory or .
// I need to let those propagate.
catch (SystemException exception)
{
    // Unless this is an I/O exception, which I don''t care about.
    if (exception is IOException)
    {
        // Ignore.
    }
    else
    {
        throw;
    }
}
// Or lock recursion exceptions, whatever those are... Probably shouldn''t hide those.
catch (LockRecursionException exception)
{
    throw;
}
// Or, uh, what else? What am I missing?
catch (???)
{
}

Answer 7

Por lo general es un error. Señales de excepción, bueno, comportamiento excepcional ; cuando se lanza una excepción, debería significar que algo salió mal. Por lo tanto, continuar el flujo normal del programa como si nada saliera mal es una forma de ocultar un error, una forma de negación. En su lugar, piense en cómo su código debe manejar el caso excepcional y escriba el código para que eso suceda. Un error que se propaga porque lo ha cubierto es mucho más difícil de depurar que uno que aparece de inmediato.

Answer 8

Sí, es incorrecto. Es como goto : uno por cada 100 KLoc está bien, pero si necesitas muchos de estos, lo estás haciendo mal.

Tragar excepciones sin ninguna reacción es una de las peores cosas en el manejo de errores, y al menos debería ser explícito:

try  
{      
   DontWannaCatchIt(); 
}  
catch 
{
    // This exception is ignored based on Spec Ref. 7.2.a,
    // the user gets a failure report from the actual results, 
    // and diagnostic details are available in the event log (as for every exception)
} 

La mirada más alejada:

El manejo de errores es un aspecto: en algunos contextos, se debe lanzar un error y propagar la pila de llamadas (por ejemplo, si copia un archivo, la copia falla).

Llamar al mismo código en un contexto diferente puede requerir que se rastree el error, pero que la operación continúe (por ejemplo, copiando 100 archivos, con un registro que indica qué archivos fallaron).

Incluso en este caso, un controlador de captura vacío es incorrecto.

Con la mayoría de los idiomas, no hay otra implementación directa que intentar + capturar dentro del bucle y construir el registro en el controlador de captura. (Sin embargo, podría crear un mecanismo flexible mroe: tenga un manejador por subproceso de llamada que puede lanzar o guardar el mensaje. Sin embargo, la interacción con las herramientas de depuración se produce sin soporte de lenguaje directo).

Un caso de uso razonable sería implementar un TryX() desde un X() , pero eso tendría que devolver la excepción en cuestión.

Answer 9

Si no quieres atraparlo, ¿por qué usas try en primer lugar?

Una declaración de try significa que usted cree que algo puede salir mal, y la catch dice que puede manejar adecuadamente lo que va mal.

Así que en su estimación:

try
{
    //Something that can go wrong
}
catch
{
    //An empty catch means I can handle whatever goes wrong. If a meteorite hits the
    //datacenter, I can handle it.
}

Esa captura se traga cualquier excepción que suceda. ¿Está tan seguro de su código que puede manejar cualquier cosa que salga mal con gracia?

Lo mejor que puede hacer (tanto para usted como para la cordura de su programador de mantenimiento) es declarar explícitamente lo que puede manejar con gracia:

try
{
    //Something that could throw MeteoriteHitDatacenterException
}
catch (MeteoriteHitDatacenterException ex)
{
    //Please log when you''re just catching something. Especially if the catch statement has side effects. Trust me.
    ErrorLog.Log(ex, "Just logging so that I have something to check later on if this happens.")

}

Answer 10

Sin captura o finalmente no es válido. La captura vacía o finalmente es válida. La captura vacía significa que no le importan las excepciones, solo intenta hacer algo y no importa si no funciona, solo quiere continuar. Útil en funciones de limpieza, por ejemplo.