c# - try - throw new invalidoperationexception
diferencia entre throw y throw new Exception() (11)
Al lanzar una nueva Excepción, se destruye el seguimiento de la pila actual.
throw; retendrá la traza original de la pila y casi siempre es más útil. La excepción a esa regla es cuando desea ajustar la Excepción en una Excepción personalizada propia. Entonces debes hacer:
catch(Exception e)
{
throw new CustomException(customMessage, e);
}
Cuál es la diferencia entre
try { ... }
catch{ throw }
y
try{ ... }
catch(Exception e) {throw new Exception(e.message) }
A pesar de que el segundo muestra un mensaje?
El primero conserva la stacktrace original:
try { ... }
catch
{
// Do something.
throw;
}
El segundo le permite cambiar el tipo de la excepción y / o el mensaje y otros datos:
try { ... } catch (Exception e)
{
throw new BarException("Something broke!");
}
También hay una tercera forma en la que pasas una excepción interna:
try { ... }
catch (FooException e) {
throw new BarException("foo", e);
}
Yo recomendaría usar:
- el primero si desea realizar una limpieza en una situación de error sin destruir información o agregar información sobre el error.
- el tercero si desea agregar más información sobre el error.
- el segundo si desea ocultar información (de usuarios que no son de confianza).
La diferencia más importante es que la segunda expresión borra el tipo de excepción. Y el tipo de excepción juega un papel vital en la captura de excepciones:
public void MyMethod ()
{
// both can throw IOException
try { foo(); } catch { throw; }
try { bar(); } catch(E) {throw new Exception(E.message); }
}
(...)
try {
MyMethod ();
} catch (IOException ex) {
Console.WriteLine ("Error with I/O"); // [1]
} catch (Exception ex) {
Console.WriteLine ("Other error"); // [2]
}
Si foo() arroja IOException , [1] catch block capturará la excepción. Pero cuando bar() arroja IOException , se convertirá en simple Exception y no será capturada por [1] catch block.
Lanzar; Retome la excepción original y mantenga el tipo de excepción.
Lanzar nueva excepción (); Vuelva a retomar el tipo de excepción original y restablezca el seguimiento de la pila de excepción
Lanzar ex; Restablezca el seguimiento de la pila de excepción y restablezca el tipo de excepción
Otro punto que no vi que hiciera nadie:
Si no haces nada en tu bloque catch {}, intentarlo ... catch no tiene sentido. Veo esto todo el tiempo:
try
{
//Code here
}
catch
{
throw;
}
O peor:
try
{
//Code here
}
catch(Exception ex)
{
throw ex;
}
Peor aún:
try
{
//Code here
}
catch(Exception ex)
{
throw new System.Exception(ex.Message);
}
Si lo desea, puede lanzar una nueva Excepción, con el conjunto original como una excepción interna.
Su segundo ejemplo restablecerá el seguimiento de la pila de la excepción. El primero conserva con mayor precisión los orígenes de la excepción. También ha desenvuelto el tipo original que es clave para saber qué salió mal ... Si el segundo es necesario para la funcionalidad, por ejemplo, para agregar información extendida o volver a envolver con un tipo especial, como una ''Excepción Handleable'' personalizada, simplemente ¡seguro de que la propiedad InnerException también está configurada!
throw o throw ex, ambos se usan para lanzar o volver a lanzar la excepción, cuando simplemente registra la información del error y no desea enviar ninguna información a la persona que llama, simplemente registra el error en catch y se va. Pero en caso de que desee enviar información significativa sobre la excepción a la persona que llama, use throw o throw ex. Ahora la diferencia entre throw y throw ex es que throw conserva el seguimiento de la pila y otra información, pero throw ex crea un nuevo objeto de excepción y, por lo tanto, se pierde la traza original de la pila. Entonces, ¿cuándo deberíamos usar throw y throw e? Aún existen algunas situaciones en las que es posible que desee volver a lanzar una excepción, como restablecer la información de la pila de llamadas. Por ejemplo, si el método está en una biblioteca y desea ocultar los detalles de la biblioteca del código de llamada, no necesariamente quiere que la pila de llamadas incluya información sobre métodos privados dentro de la biblioteca. En ese caso, podría detectar excepciones en los métodos públicos de la biblioteca y luego volver a lanzarlos para que la pila de llamadas comience en esos métodos públicos.
throw; vuelve a lanzar la excepción original y conserva su traza de pila original.
throw ex; arroja la excepción original pero restablece el seguimiento de la pila, destruyendo toda la información de seguimiento de la pila hasta su bloque catch .
NUNCA escribir throw ex;
throw new Exception(ex.Message); es aún peor Crea una nueva instancia de Exception , perdiendo el rastro de la pila original de la excepción, así como su tipo. (por ejemplo, IOException ).
Además, algunas excepciones contienen información adicional (por ejemplo, ArgumentException.ParamName ).
throw new Exception(ex.Message); destruirá esta información también
En ciertos casos, es posible que desee ajustar todas las excepciones en un objeto de excepción personalizado, para que pueda proporcionar información adicional sobre lo que estaba haciendo el código cuando se lanzó la excepción.
Para hacer esto, defina una nueva clase que hereda Exception , agregue los cuatro constructores de excepción y, opcionalmente, un constructor adicional que tome una InnerException además de información adicional, y InnerException su nueva clase de excepción, pasando ex como el parámetro InnerException . Al pasar la InnerException original, conserva todas las propiedades de la excepción original, incluido el seguimiento de la pila.
throw es para volver a lanzar una excepción atrapada. Esto puede ser útil si desea hacer algo con la excepción antes de pasarlo por la cadena de llamadas.
El uso de throw sin argumentos conserva la pila de llamadas para fines de depuración.
throw re-arroja la excepción atrapada, reteniendo el rastro de la pila, mientras throw new Exception pierde algunos de los detalles de la excepción atrapada.
Normalmente usaría throw por sí mismo para registrar una excepción sin manejarla completamente en ese punto.
BlackWasp tiene un buen artículo suficientemente titulado Throwing Exceptions in C # .