propias - tipos de excepciones en java netbeans
¿Cuándo deberíamos crear nuestras propias clases de excepción java? (5)
desde un buen punto de vista de diseño / práctica, ¿cuándo deberíamos crear y usar clases de excepción java personalizadas en lugar de las ya predefinidas en java?
En algunas aplicaciones veo que casi no se crean clases de excepciones personalizadas, o incluso ninguna, sino que se esfuerzan por utilizar siempre las excepciones nativas de Java. Por otro lado, hay algunas aplicaciones que definen excepciones personalizadas para todo.
cual es la mejor practica?
¡Gracias!
desde un buen punto de vista de diseño / práctica, ¿cuándo deberíamos crear y usar clases de excepción java personalizadas en lugar de las ya predefinidas en java?
Cuando los nombres de excepción existentes no cubren su necesidad.
Otra preocupación de diseño es extender la clase de excepción "buena"; por ejemplo, si genera una excepción relacionada con E / S, lo ideal sería heredar IOException ; si la excepción indica un error del programador, debe heredar RuntimeException (es decir, hacer que su excepción no se verifique).
La creación de excepciones personalizadas también le permite tratar las excepciones de una manera más precisa; por ejemplo, si ha definido FooException heredando IOException , entonces puede tener un tratamiento especial para ello:
try { ... }
catch (FooException e) { ... } // Catch it _before_ IOException!
catch (IOException e) { ... }
Además, las excepciones son clases como cualquier otra, por lo que puede agregar métodos personalizados, etc. por ejemplo, Jackson define JsonProcessingException que hereda IOException . Si lo .getLocation() , puede obtener información de ubicación del error de análisis mediante .getLocation() .
A menudo creo excepciones personalizadas si hay más información que necesito transmitir en lugar de solo un mensaje de error.
Por ejemplo, códigos de error particulares o valores reales frente a valores esperados. estos también pueden tener sus propios captadores para que pueda recuperarlos de forma programática sin tener que analizar el mensaje Cadena, que podría romperse si alguna vez cambia el texto del mensaje. (O traducirlo a un idioma diferente)
Si crea sus propias excepciones, le recomiendo que MycustomIOException excepciones integradas comunes de JDK para que su API pueda decir que throws IOException pero realmente arroja MycustomIOException . De esta manera, los usuarios de su API no tienen que saber sobre sus propias versiones personalizadas a menos que lo deseen.
Ciertamente, cuando espera poder manejar una excepción mediante programación, es decir, es fácil crear declaraciones catch separadas para diferentes tipos de excepciones, es decir:
try{
buyWidgets();
}
catch(AuthenticationException ex)
{
promptForLogin();
}
catch(InsufficientFundsException ex)
{
promptToRefillAccount();
}
//let other types of exceptions to propagate up the call stack
Sobre si lo anterior constituye uso inapropiado de excepción para control de flujo
Si bien las excepciones son más costosas para CPU que las sentencias if-else (principalmente debido al costo de construir un seguimiento de pila), el costo es relativo y debe evaluarse en el contexto de un caso de uso particular. No todas las partes del código deben ser rápidas a escala de la web y algunas personas consideran que la lectura y las condiciones de prueba son más engorrosas. Por ejemplo, casi todos los gestores de transacciones implementan modismos de retrotraer-reintentar utilizando excepciones. (Intente escribir un aspecto de reintento de transacción sin detectar una excepción)
Por separado, uno debe adherirse al principio de la separación de las preocupaciones: no todas las partes del código deben tratar con todas las condiciones posibles. Si no está conectado mientras compra widgets es un caso excepcional que realmente depende de la aplicación y el lugar particular en la base de código de la aplicación. Por ejemplo, podría tener un Servicio con operaciones para usuarios que hayan iniciado sesión. No tiene sentido que los métodos en ese servicio se ocupen de la autenticación; en su lugar, estos métodos esperarían que el código estuviera más temprano en la cadena de llamadas para garantizar que el usuario esté autenticado y, por lo tanto, simplemente lanzarán excepciones si no es así. Por lo tanto, para aquellos métodos que no están conectados ES un caso excepcional.
De las mejores prácticas para el manejo de excepciones :
Intente no crear nuevas excepciones personalizadas si no tienen información útil para el código del cliente.
¿Qué pasa con el siguiente código?
public class DuplicateUsernameException extends Exception {}
No está dando ninguna información útil al código del cliente, que no sea un nombre de excepción indicativo. No olvide que las clases de excepción de Java son como otras clases, en las que puede agregar métodos que cree que el código del cliente invocará para obtener más información.
Podríamos agregar métodos útiles a DuplicateUsernameException , como por ejemplo:
public class DuplicateUsernameException
extends Exception {
public DuplicateUsernameException
(String username){....}
public String requestedUsername(){...}
public String[] availableNames(){...}
}
La nueva versión proporciona dos métodos útiles: requestedUsername() , que devuelve el nombre solicitado, y availableNames() , que devuelve una matriz de nombres de usuario disponibles similar a la solicitada. El cliente podría usar estos métodos para informar que el nombre de usuario solicitado no está disponible y que otros nombres de usuario están disponibles. Pero si no va a agregar información adicional, solo arroje una excepción estándar:
throw new IllegalArgumentException("Username already taken");
Es bueno tener excepciones personalizadas en su aplicación, una puede ser una excepción personalizada de primer nivel para aplicaciones, otras en los niveles de módulo / paquete. Si tiene alguna función / operación específica en la aplicación y necesita hacerle saber al usuario si se produjo alguna excepción durante la operación, entonces es mejor agregar una excepción personalizada para esa operación. Será fácil depurar / investigar los problemas.