¿Cuál es la diferencia entre:Usando captura sin argumentos
catch
{
MessageBox.Show("Error.");
}
y:
catch (Exception ex)
{
MessageBox.Show("Error.");
//we never use ex, so is it better to use catch without arguments?
}
¿A partir de .NET 2, si no modifica la configuración? Nada.
Antes de eso, o con algún pellizco de configuración no puedo recordar con precisión, existía la posibilidad de una excepción que es lanzado desde código no administrado, que no hicieron llegar convierte en un objeto compatible con Exception.
Tenga en cuenta que no hay otra opción en el medio, donde se especifica el tipo, pero ninguna variable:
catch (Exception)
{
...
}
Personalmente me gustaría ser muy cuidadoso de la captura de una excepción sin siquiera tala ella. Puede ser necesario si está llamando a una API desquiciada, pero generalmente es mejor evitarla.
"existía la posibilidad de que se lanzara una excepción del código no administrado que no se obtuvo ..." ¿De modo que de 2.0 en adelante se convierte en Excepción compatible? es decir, ahora cualquier cosa lanzada por administrado o no será capturada por catch (Exception e) {} también. Por cierto, sí intenté experimentar con la biblioteca de Outlook Interop, pero no estoy seguro de cómo obtener un error de código no administrado. – devanalyst
@devanalyst: Sí, creo * todo se convierte en 'Excepción' ahora. –
@JonSkeet: ¿Pero cuál es la diferencia entre 'catch',' catch (Exception) 'y' catch (Exception ex) '? El primero no hace más que atrapar todo, el segundo solo el tipo, y el tercero también los detalles. ¿Qué debería atrapar aparte de una excepción? – testing
En el segundo ejemplo se puede hacer referencia a datos de excepción, como el seguimiento de la pila, fuente, etc. También da un mensaje general que a veces es útil. Te dice POR QUÉ sufriste una excepción que es importante cuando se depura.
Creo que no entendió el punto, el primero atrapa todas las excepciones, el segundo atrapa las excepciones .NET –
En realidad, lo único que preguntaron fue cuál es la diferencia entre dos ejemplos de captura y esa es la diferencia. Ya sea que hagas referencia a la excepción o no. Y para que lo sepas, ambos ejemplos captan todas las excepciones .Net. Cualquier excepción que capture será una "excepción .Net" porque es C#. También es importante tener en cuenta que todas las excepciones tienen la clase Exception en su árbol de herencia porque una clase de excepción debe heredarlo directa o indirectamente al heredar de otra clase que haya heredado la clase Exception. – jlafay
está equivocado, algunas excepciones no heredan de Exception. Las creadas por código de usuario, o el código C#, sí, pero otras no –
En general, primero debe detectar los errores específicos.
Pero si vas para la captura de un general Exception como lo hace yo diría que el uso del segundo caso:
catch (Exception ex)
{
MessageBox.Show("Error.");
//we never use ex, so is it better to use catch without arguments?
}
esto le puede ayudar con debbuging ya que la variable contiene el seguimiento de la pila, mensaje de excepción .. .etc. Que puede usar para registrar el error o algo que lo ayudará a prevenirlo.
Tenga mucho cuidado con este enfoque, sin embargo:
MessageBox.Show("Error.");
No mantener un registro de sus errores en alguna parte (como un archivo de registro) puede provocar realmente un gran lío.
De todos modos, se puede acceder a los datos de excepción. Si entra en una excepción sin una variable, aparecerá un símbolo que le mostrará datos de excepción. – GeirGrusom
@GeirGrusom - sí, pero no puede usar esa información para iniciar sesión en un archivo o algo así podemos hacer? – TheBoyan
@GeirGrusom seguro, puede ver la excepción cuando está depurando, pero no tiene una referencia para usar al iniciar sesión o mostrar el mensaje apropiado al usuario. – DOK
Creo que son lo mismo. Pero el segundo caso generó una advertencia de compilación porque usted declara una excepción que no utilizó. Me gusta bastante el primero porque dices explícitamente que no usas la excepción. También hay un tercero
catch (Exception)
{
//do something
}
si desea especificar el tipo de excepción pero no le importa la excepción en sí.
¿Significa esto que si se lanza una excepción, todavía entra dentro del bloque catch, incluso si no hacemos nada con la excepción? –
Algunas excepciones no pueden ser catch(Exception) atrapados.
Debajo de la excecption en mono en linux, debe capturar sin parámetro.
De lo contrario, el tiempo de ejecución ignorará la declaración catch(Exception).
System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.
Si se encuentra con el problema de esa manera, tratar de eliminar el parámetro de catch declaración, ingrese el contexto vars para averiguar la causa del error.
P.S. No sé cómo en Windows, el programa que se ejecuta en Windows es normal.
Lea esto: http://msdn.microsoft.com/en-us/library/0yd65esw(VS.80).aspx – JonH
En el segundo caso, use 'catch (Exception)' si desea capturar ese tipo o tipos derivados de excepciones, pero no quieren saber los detalles. De lo contrario, recibirá una advertencia y declarará una variable cuando no sea necesaria –