¿Suprimir-atrapar o lanzar excepciones que nunca pueden ocurrir?

Question

Decir que tengo la siguiente línea en un método:

String encodedString = URLEncoder.encode(foo, "utf-8"); 

este método produce una UnsupportedEncodingException. ¿Qué es mejor:

/** @throws UnsupportedEncodingException umm...never 
*/ 
public void myMethod() throws UnsupportedEncodingException { 
    ... 
    String encodedString = URLEncoder.encode(foo, "utf-8"); 
    ... 
} 

(obligando a la persona que llama para atrapar a este mismo) O:

public void myMethod() { 
    try { 
    ... 
    String encodedString = URLEncoder.encode(foo, "utf-8"); 
    ... 
    catch(UnsupportedEncodingException e) { 
     Logger.log("cosmic ray detected!"); 
    } 

} 

O hay una forma más elegante de manejar excepciones que no pueden realmente ha ocurrido?

Answer 1

Nunca digas nunca;)

En el ejemplo anterior siempre se puede detectar la excepción luego tirar un RuntimeException:

public void myMethod() { 
    try { 
     ... 
     String encodedString = URLEncoder.encode(foo, "utf-8"); 
     ... 
    } catch(UnsupportedEncodingException e) { 
    throw new RuntimeException("This should not be possible",e); 
    } 

} 

De esta manera la persona que llama no está obligado a coger algo que 99,999% seguro nunca sucederá, pero en el caso de que ocurra, todavía obtienes una burbuja de excepción hasta el punto en que con suerte lo notarás y podrás darte cuenta rápidamente de lo que ha cambiado y solucionarlo.

HTH

Answer 2

Si puede casi garantizar que la excepción no puede ocurrir, entonces es mejor para localizar esta afirmación en el alcance más estrecho en lugar de dejar que se propague, porque otras personas pueden no darse cuenta de que este es el caso sin tener en cuenta documentaciones.

Si se declara que un método arroja algo, entonces debe haber escenarios donde realmente lo haga. Si está garantizado que nunca lo hace, entonces es mejor omitir la cláusula throws y simplificar su API.

Siempre debe lanzar excepciones apropiadas para su nivel de abstracción (Effective Java 2nd Edition, ítem 61). Declarar que puede tirar algo, cuando nunca se ha garantizado, rompe esta guía de diseño.