¿La mala práctica de "arrojar excepciones" es?

Question

estoy revisando el código de un colega y me encuentro con un trozo de código similar al siguiente:

public X Foo1(Y y) throws Exception { 
    X result = new X(y); 
    result.Foo2(); 
    return result; 
} 

Creo que no hay necesidad de throws Exception parte pero estoy teniendo dificultades para justificar esto. Podría tener sentido si fuera más específico Exception (FileNotFound, NoMemory etc.) pero como es, creo que no es necesario. ¿Puede alguien darme algunas razones sobre los problemas que esto puede causar y por qué es una mala práctica? ¿O este código está bien?

Answer 1

La declaración throws es parte del contrato de método. Siempre debe ser como lo más preciso posible al definir los contratos. Diciendo throws Exception es una mala idea.

Es malo por la misma razón que es una mala práctica decir que un método devuelve Object cuando se garantiza que devuelve String.

Además, una persona que llama del método necesariamente debe atrapar Exception (a menos que desee propagar esta fealdad), y capturar Exception también es una mala idea. Vea las respuestas a esta pregunta: Is it a bad practice to catch Throwable?

Answer 2

Esto obliga a todos los usuarios de este método a manejar Excepciones lanzadas.

Incluso si te gusta usar las excepciones marcadas (que yo no), esto te deja sin información sobre qué tipo de cosas pueden salir mal. Entonces no puedes manejarlo de una manera significativa.

Answer 3

Lanza declaración significa que: - algo dentro de su método puede producir tales excepción comprobada - su método no puede o no tratar con él

Usted deberá utilizar excepción más específica, y se resisten a la tentación de grupo no relacionada excepciones para reducir la cantidad de declaraciones de lanzamientos. Si sientes que hay demasiados, entonces tu método es demasiado complicado y se dividirá en más pequeños métodos más manejables