java.lang.Exception frente a su propia excepción

Question

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

Answer 1

Creo que debe hacerse una pregunta ligeramente diferente "¿Qué ventaja tiene la creación de un nuevo ¿Qué excepción me dan los 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?

discusión más profunda: Custom exceptions: When should you create them?

Answer 2

Cuando quiero tratar a mis excepciones diferente a todos 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 3

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

Existe una tendencia en los programadores novatos 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 4

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

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

2. Si hay excepciones que deben manejarse, esas pueden definirse simplemente en throws o envueltas en alguna excepción de tiempo de ejecución o en wrap 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, vuelva y cree una nueva excepción para ella.

El objetivo es evitar hacer trabajo extra antes de saber qué se necesita.

Answer 5

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

Answer 6

Motivo 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} 
    } 
} 

Es probable que desee 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 haber una subclase de RuntimeException

Razón dos:

consolidación API. Si escribir una interfaz y tiene varias implementaciones, es posible que ellos llamarán diferentes APIs con un montón de diferentes no RuntimeExceptions tirado:

interface MyInterface { 
    void methodA(); 
} 

class MyImplA { 
    void methodA() throws SQLException { ... } 
} 

class MyImplB { 
    void methodA() throws IOException { ... } 
} 

Está seguro de querer MyInterface.methodA para lanzar excepción de SQL 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 7

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 el mínimo invariable < = 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 8

creo que:

catch (Exception e) { 
    ... 
} 

... es un anti patrón que debe ser evitado. 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.

qué:

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

por lo que tratar de 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.

Answer 9

No puedo imaginar lanzar específicamente una 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 10

El software captura el significado.

No hay casi ninguna razón 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 un DataFormatException debido a un algoritmo de análisis que ha escrito. 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 excepción clase 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 a Java.]