Cómo lidiar con excepciones comprobadas que nunca se pueden lanzar

Ejemplo:

foobar = new InputStreamReader(p.getInputStream(), "ISO-8859-1");

Dado que la codificación está codificada y es correcta, el constructor nunca arrojará la excepción UnsupportedEncodingException declarada en la especificación (a menos que la implementación de Java esté rota, en cuyo caso me perderé de todos modos). De todos modos, Java me obliga a lidiar con esa excepción de todos modos.

Actualmente, se ve así

try {
    foobar = new InputStreamReader(p.getInputStream(), "ISO-8859-1");
}
catch(UnsupportedEncodingException e) { /* won't ever happen */ }

¿Alguna idea de cómo mejorarlo?

Mi hábito es, solo estar en el lado seguro, poner un assertbloque de captura. Alguien podría cambiar el contenido del trybloque más tarde, y usted desea saber si el código falla, ¿no?

Si me hubieran dado un centavo por cada vez que he visto un registro / error, "Esto nunca debería suceder", tendría ... bueno, dos centavos. Pero aún...

Los bloques de captura vacíos hacen que mis sentidos de araña tiemblen y la mayoría de las buenas herramientas de análisis de código se quejan. Evitaría a toda costa dejarlos vacíos. Claro, ahora sabe que el error nunca puede suceder, pero dentro de un año alguien realiza una búsqueda global de "ISO-8859-1" y de repente puede tener un error extremadamente difícil de encontrar.

La assert falsesugerencia es buena, pero dado que las afirmaciones se pueden deshabilitar en tiempo de ejecución, no son garantía. Yo usaría un RuntimeExceptionen su lugar. No tendrá que atraparlos llamando a clases y si alguna vez ocurren, tendrá un seguimiento de la pila para proporcionar información completa.

Siempre lo he hecho así:

try {
    foobar = new InputStreamReader(p.getInputStream(), "ISO-8859-1");
} catch(UnsupportedEncodingException e) {
    throw new AssertionError(e);
}

Puede ser un poco detallado (Java es ...), pero al menos obtendrá un error de aserción cuando ocurra lo imposible.

Si la implementación de Java está rota, querrás obtener el mejor mensaje de error posible, lo más rápido posible, en lugar de ignorar lo imposible. E incluso si la implementación de Java no está rota, alguien podría haber cambiado su código a "UTF8"(¡vaya! ¿Debería haberlo estado "UTF-8"?).

Esto debería haber sido una excepción en tiempo de ejecución en primer lugar. JDK está lleno de este tipo de elecciones equivocadas.

Si usted es el único desarrollador que podrá ver este código, entonces diría que está bien, pero si no lo es, lo trataría como una posibilidad real o al menos cambiaría el comentario "nunca sucederá" a Algo más útil.

La parte de estas excepciones que más me molesta es que perjudica la cobertura de mi código.

Cuando me vuelva compulsivo acerca de la cobertura, enrollaré el try / catch que "nunca puede suceder" (... o solo si estoy usando una JVM mutante que de alguna manera olvidó incluir "US-ASCII") en una clase y un método que encapsula ese try / catch y reemplaza la excepción marcada en una de las formas mencionadas aquí (por lo general, arroja una excepción no verificada con un mensaje sarcástico).

Luego, la cobertura de mi código se ve afectada en la clase de utilidad, pero no en todas las referencias a esa operación dispersas por mi código.

A veces me tomo el tiempo de pasar como operaciones en una clase que en realidad tiene una semántica coherente. Pero dado que es bastante obvio para mis compañeros de equipo lo que está sucediendo, generalmente lo mantengo lo más simple posible y no me preocupo tanto por el mejor diseño posible.

Sin embargo, como se menciona en un comentario, Guava y otras bibliotecas tienen formas de mitigar este dolor, pero esa es básicamente la misma estrategia. Mueva la molestia fuera del escenario para que su código principal no se vea afectado en la cobertura.