todas - java.lang.Exception vs. rolling tu propia excepción

todas las excepciones en java

Question

¿En qué punto crearías tu propia clase de excepción frente a usar java.lang.Exception? (¿Todo el tiempo? ¿Solo si se usará fuera del paquete? ¿Solo si debe contener una lógica avanzada? Etc ...)

Answer 1

Comience siempre usando las clases de excepciones comunes y cuando parezca que hay una necesidad especial para manejarlo, cámbielo.

1. Al crear un método por primera vez, solo deja pasar las excepciones.

2. Si hay excepciones que deben manejarse, estas pueden definirse simplemente en throws o envueltas en alguna excepción de tiempo de ejecución o excepción envuelta de throw throws. Prefiero las excepciones de tiempo de ejecución en muchos casos. Se debe evitar la definición de definiciones de lanzamientos hasta que sea necesario desde el punto de vista de la API.

3. Más adelante, cuando parece que una necesidad hace un manejo específico para una excepción en alguna persona que llama, regrese y cree una nueva excepción para ella.

El punto es evitar hacer trabajo extra antes de saber lo que se necesita.

Answer 2

Creo que debes hacerte una pregunta ligeramente diferente "¿Qué ventaja me aporta crear una nueva excepción o desarrolladores que usan mi código?" Realmente, la única ventaja que le da a usted u otras personas es la capacidad de manejar la excepción. Parece una respuesta obvia pero realmente no lo es. Solo debe manejar excepciones de las que pueda recuperarse razonablemente. Si la excepción que lanzas es un error realmente fatal, ¿por qué darles a los desarrolladores la oportunidad de manipularlo mal?

Más discusión en profundidad: excepciones personalizadas: ¿cuándo se deben crear?

Answer 3

Cuando quiero tratar mis excepciones de forma diferente a las de los demás. Si quiero atrapar el mío y propagar el de los demás, o si quiero atrapar el de alguien más y propagar el mío, o si quiero atrapar ambos pero tratarlos de manera diferente, entonces definiré una clase separada para mis excepciones. Si quiero tratarlos todos igual, ya sea al propagar ambos o capturar ambos (y hacer lo mismo de cualquier forma con las excepciones detectadas), usaré la clase estándar.

Answer 4

El software captura el significado.

Casi no hay motivos para lanzar una excepción existente: la JVM ya lo hace por usted. Su versión de su excepción no es realmente precisa y arrojar "Excepción" tampoco es significativa.

Es posible que tenga una DataFormatException debido a un algoritmo de análisis que escribió. Esto, sin embargo, es raro.

Cuando su programa encuentra una situación excepcional, casi siempre es exclusivo de su programa. ¿Por qué adaptar su situación excepcional a una excepción existente? Si es exclusivo de tu programa, entonces ... bueno ... es único. Nómbralo de esa manera.

No obstante, no proporcione una clase de excepción única para cada mensaje único. Una clase de excepción puede tener muchos mensajes variantes y detalles de soporte.

La regla de oro de Python, traducida a Java, es definir cualquier excepción única a nivel de paquete. [En Python, sugieren excepciones a nivel de "módulo", algo que no se traduce precisamente en Java.]

Answer 5

En la mayoría de los casos, no tiene sentido crear su propia clase de excepción.

Los programadores novatos tienden a crear su propia clase de excepción solo para que puedan usar un nombre que sea más indicativo del tipo de error. Por lo tanto, encontrará clases como FTPInitializationException, DAOFactoryException, etc. aunque tales excepciones no se manejen de forma diferente a las excepciones estándar. Este es claramente un patrón anti que debe evitarse.

Answer 6

No puedo imaginar lanzar específicamente una excepción java.lang.Exception si algún objeto / clase / método tuvo un problema. Es demasiado genérico: si no va a crear su propia clase de excepción, me parece que al menos debería haber un tipo de excepción más específico en la API.

Answer 7

Razón uno:

Necesito atrapar cosas específicas. Si el código de llamada necesita tratar una condición excepcional específica, debe diferenciar su Excepción, y Java diferencia las excepciones con diferentes tipos, por lo que debe escribir la suya propia.

Básicamente, si alguien tiene que escribir:

catch(ExistingException e) {
if({condition}) {
{ some stuff here}
}
else {
{ different stuff here}
}
}

Probablemente quiera escribir una extensión específica; catch La coincidencia de excepciones es más clara que la de condicionales, en mi humilde opinión.

Recuerde: su nueva excepción puede ser una subclase de RuntimeException

Razón dos:

Consolidación de API. Si escribe una interfaz y tiene varias implementaciones, es posible que invoquen diferentes API con un montón de diferentes no-RuntimeExceptions lanzados:

interface MyInterface {
void methodA();
}
class MyImplA {
void methodA() throws SQLException { ... }
}
class MyImplB {
void methodA() throws IOException { ... }
}

¿Realmente quieres MyInterface.methodA para lanzar SQLException y IOException? Tal vez entonces tenga sentido ajustar las posibles excepciones en una Excepción personalizada. Que de nuevo puede ser una RuntimeException. O incluso RuntimeException en sí ...

Answer 8

SI hay una Excepción existente con el idioma de ejecución o bibliotecas, úsela ELSE cree la suya, documente bien y eso debería funcionar en el 99% de los casos.

Answer 9

Usaría las excepciones de la API de Java cuando la excepción se relaciona con la API. Pero si surge una situación excepcional que es exclusiva de mi propia API, entonces crearé una Excepción para ella. Por ejemplo, si tengo un objeto Range con dos propiedades min y max y la invariante min <= max, entonces crearé una excepción InvalidRangeException.

Cuando estoy escribiendo código, esto ayuda porque sé si la excepción se origina porque violé una de mis propias condiciones o algo de la API de Java.

Answer 10

Yo creo eso:

catch (Exception e) {
...
}

... es un antipatrón que debe evitarse. Es posible que desee una captura amplia centralizada en alguna parte de la aplicación, registrar un error y evitar que la aplicación final termine, pero tenerlos diseminados por doquier es malo.

Por qué:

try {
if(myShape.isHidden()) {
throw new Exception();
}
// More logic
} catch (Exception e) {
MyApp.notify("Can''t munge a hidden shape");
}

Entonces prueba esto, y debido a un error de codificación, myShape es nulo. Se lanza una excepción NullPointerException cuando el tiempo de ejecución intenta desvincular myShape. Este código informa una forma oculta, cuando debería informar un puntero nulo.

Haga su propia excepción o busque una excepción especializada adecuada en la API. No es como si extender Exception o RuntimeException fuera oneroso.