Eso no es terrible en sí mismo, pero uno realmente debería mirar el anidamiento.
El caso de uso aceptable es como tal:
Soy un componente de bajo-ish que pueden encontrarse con una serie de diferentes errores sin embargo mi consumidor sólo está interesado en un tipo específico de excepción. Por lo tanto puedo hacer esto:
catch(IOException ex)
{
throw new PlatformException("some additional context", ex);
}
Ahora bien, esto permite que el consumidor debe hacer:
try
{
component.TryThing();
}
catch(PlatformException ex)
{
// handle error
}
Sí, sé que algunas personas dirán pero el consumidor debe coger el IOException pero esto depende de la forma abstracta del el código de consumo en realidad lo es. ¿Qué pasa si el Impl está guardando algo en el disco y el consumidor no tiene una razón válida para pensar que su operación tocará el disco? En tal escenario, no tendría sentido poner este manejo de excepciones en el código de consumo.
Lo que generalmente tratamos de evitar utilizando este patrón es colocar un manejador de excepción "catch-all" en el código de lógica de negocios porque queremos descubrir todos los posibles tipos de excepciones, ya que pueden conducir a un problema más fundamental eso necesita ser investigado Si no detectamos, se dispara, toca el controlador de nivel "superior superior" y debe detener la aplicación de ir más allá. Esto significa que el cliente informará esa excepción y tendrá la oportunidad de investigarla. Esto es importante cuando intenta construir un software robusto. Necesita encontrar todos estos casos de error y escribir un código específico para manejarlos.
Lo que no es muy bonito es anidar estas cantidades excesivas y ese es el problema que debe resolver con este código.
Como otro cartel declaró que las excepciones son para un comportamiento razonablemente excepcional, pero no lleve esto demasiado lejos. Básicamente, el código debe expresar la operación "normal" y las excepciones deben manejar los posibles problemas que pueda encontrar.
En términos de rendimiento, las excepciones son buenas, obtendrá resultados horribles si realiza una prueba con un depurador en un dispositivo incrustado pero en la versión sin un depurador, en realidad son bastante rápidas.
Lo principal que las personas olvidan al hablar sobre el rendimiento de las excepciones es que en los casos de error todo se ralentiza de todos modos porque el usuario ha encontrado un problema. ¿Realmente nos importa la velocidad cuando la red no funciona y el usuario no puede guardar su trabajo? Dudo mucho que el informe de error vuelva al usuario unos pocos ms más rápido va a hacer una diferencia.
La directriz principal para recordar cuando se discuten las excepciones es que Las excepciones no deben ocurrir dentro del flujo de aplicación normal (significado normal sin errores). Todo lo demás proviene de esa declaración.
En el ejemplo exacto que das, no estoy seguro. Me parece que no se obtiene realmente ningún beneficio al ajustar lo que parece ser una excepción tcl genérica en otra excepción de tcl que suena genérica. En todo caso, sugeriría buscar al creador original del código y saber si existe alguna lógica particular detrás de su pensamiento. Lo más probable es que puedas matar la captura.
El bloque catch que se muestra aquí agrega información adicional al objeto de excepción, lo que puede justificar su presencia. Pero si el bloque catch es inútil, elimínalo. – Qwertie