Lo que se reduce a qué herramienta se necesita para hacer el trabajo.
Las excepciones son una herramienta muy poderosa. Antes de usarlos, pregúnteles si necesitan este poder y la complejidad que conlleva.
Las excepciones pueden parecer simples, porque usted sabe que cuando se golpea la línea con la excepción, todo se detiene. ¿Qué pasa desde aquí?
¿Se producirá una excepción no detectada?
¿La excepción será atrapada por el manejo de error global?
¿La excepción se manejará mediante un manejo de errores más anidado y detallado?
Tienes que saber todo en la pila para saber qué hará esa excepción. Esto viola el concepto de independencia. Ese método ahora depende del manejo de errores para hacer lo que usted espera.
Si tengo un método no me importa lo que está fuera de ese método. Solo me debería importar cuál es la entrada, cómo procesarla y cómo devolver la respuesta.
Cuando utiliza una excepción, básicamente está diciendo, no me importa lo que pase desde aquí, algo salió mal y no quiero que empeore, haga lo que sea necesario para mitigar el problema.
Ahora si te importa cómo manejar el error, tendrás que pensar un poco más y compilarlo en la interfaz del método, p. si intenta encontrar algún objeto, posiblemente devuelva el valor predeterminado de ese objeto si no se puede encontrar uno en lugar de arrojar alguna excepción como "Objeto no encontrado".
Cuando crea errores en la interfaz de métodos, la firma de este método no solo es más descriptiva de lo que puede hacer, sino que impone la responsabilidad de cómo manejar el error en la persona que llama del método. El método del que llama puede ser capaz de resolverlo o no, y de lo contrario informaría de nuevo en la cadena. Eventualmente llegarás al punto de entrada de la aplicación. Ahora sería apropiado emitir una excepción, ya que es mejor que comprenda cómo se manejarán las excepciones si trabaja con la interfaz pública de las aplicaciones.
Déjeme darle un ejemplo de mi manejo de errores para un servicio web.
Nivel 1. Manejo global de errores en global.asax: esa es la red de seguridad para evitar excepciones no detectadas. Esto nunca debería ser intencionalmente alcanzado.
Nivel 2. Método de servicio web - Envuelto en un try/catch para garantizar que siempre cumpla con su interfaz json.
Nivel 3. Métodos de trabajador: estos obtienen datos, lo procesan y lo devuelven sin formato al método del servicio web.
En los métodos de trabajador no es correcto lanzar una excepción. Sí, tengo el manejo de errores del método de servicio web anidado, pero ese método se puede usar en otros lugares donde esto puede no existir.
En cambio, si se usa un método de trabajador para obtener un registro y no se puede encontrar el registro, simplemente devuelve nulo. El método del servicio web verifica la respuesta y cuando lo encuentra nulo, sabe que no puede continuar. El método de servicio web sabe que tiene un manejo de error para devolver json, por lo que lanzar una excepción simplemente devolverá los detalles en términos de lo sucedido. Desde la perspectiva de un cliente, es genial que se haya empaquetado en json que se pueda analizar fácilmente.
Verá que cada pieza solo sabe lo que tiene que hacer y lo hace. Cuando lanza una excepción en la mezcla, secuestra el flujo de aplicaciones. Esto no solo lleva a un código difícil de seguir, sino que la respuesta al abuso de excepciones es el try/catch.Ahora es más probable que abuse de otra herramienta muy poderosa.
Demasiado a menudo veo un try/catch atrapando todo en el medio de una aplicación, porque el desarrollador tiene miedo de que el método que usan sea más complejo de lo que parece.
+1, me gusta implementar excepciones en mi propio código, para marcar elementos que requieren trabajo (es decir: No disponible), o para obtener informes de errores más detallados de errores específicos (es decir, operaciones de archivos de E/S). Los dejo burbujear hasta cierto nivel y luego enviarlos por correo electrónico a mí mismo. ¡Bueno para probar! –
De acuerdo, la comunicación de error arrojando excepciones tiene su lugar. – jpoh