¿Cómo se manejan las excepciones "imposibles" en Java?

Question

A veces, voy a terminar encima de tener que capturar una excepción, que yo sepa nunca puede pasar, como aquí

URLDecoder.decode("some string", "UTF-8"); //No unknown encoding possible 

o aquí:

public void methodWithURL(URL url){ 
    URI uri = new URI(url); //No invalud URI syntax possible 
} 

¿cómo manejar esto? En general, registro un error gracioso con respecto a cómo han cambiado las leyes del universo, y luego lanzo un RuntimeException. ¿Hay una mejor manera?

Answer 1

Cojo el Exception y lo envuelvo en un Error. Del documento de Error:

Un error es una subclase de Throwable que indica problemas serios que una aplicación razonable no debe tratar de atrapar.

Answer 2

Bueno, en mi humilde opinión es una mejor manera que "registrar [ging] un error gracioso con respecto a cómo las leyes del universo han cambiado" porque al hacerlo estás "siendo lindo", que entre amigos está bien, pero no es universal (sin juego de palabras) aceptado. Su código puede ser leído por otros y si su humor no es claro (en ellos) realmente no ha hecho ningún amigo.

Muchas guías de estilo hacen sugerencias para excepciones imposibles. Puede usar un bloque de catch vacío con el parámetro de excepción llamado willNeverHappen; puedes colocar un comentario en el bloque vacío; usted puede lanzar una excepción de tiempo de ejecución (probablemente la mejor, ya que FUERZA misspell UTF-8!)

Si quieres ser súper ambiciosa, puede escribir una anotación, como SneakyThrows in Lombok. Si lo considerarías "mejor" es simplemente una cuestión de gusto. :)

Tenga en cuenta que esta pregunta se discutió en https://softwareengineering.stackexchange.com/questions/122233/how-to-deal-with-checked-exceptions-that-cannot-ever-be-thrown.

Answer 3

Me saltaría el mensaje gracioso.

BTW: Tuve un caso en el que un fragmento de código (en una pequeña biblioteca) simplemente suponía que una codificación estaría disponible. Solo se desplegó en un dispositivo limitado y explotó en tiempo de ejecución.

Las excepciones comprobadas sirven para mostrar lugares en nuestro código donde deberíamos detenernos un momento y considerar las rutas menos transitadas (como en "lo que hace mi aplicación cuando la red muere" y otros casos de esquina). Envolverlos en IllegalStateException y reingresar es una especie de contrato firmado, donde el programador dice: "sí, todos los riesgos considerados, yo asumo la plena responsabilidad del lugar justo aquí". Si no fuera por las excepciones marcadas, no tendríamos forma de saber una decisión conciente de una simple falta de pensamiento.

Answer 4

aquí está mi solución - desarrollado para Android, pero puede adaptarse fácilmente para Java "regular":

public class ImpossibleException extends RuntimeException { 
    public ImpossibleException(@NonNull String whyNotPossible) { 
     this(whyNotPossible, null); 
    } 

    public ImpossibleException(@NonNull String whyNotPossible, Throwable throwable) { 
     super("Impossible exception: " + whyNotPossible, throwable); 
     Log.e("Impossible", whyNotPossible, throwable); 
    } 
} 

Uso:

try { 
    byte[] data = "Hello".getBytes("utf-8"); 
    Log.i("Test", "data.length=" + data.length); 
} catch (UnsupportedEncodingException e) { 
    throw new ImpossibleException("Android always supports utf-8", e); 
} 

significa El constructor whyNotPossible no hay necesidad de registrar el error donde sucede, y tampoco hay necesidad de un comentario.

Supongo que es una cuestión de gusto si esto debería ser un ImpossibleException extends RuntimeException o un ImpossibleError extends Error.