The case against checked exception

Durante varios años, no he podido obtener una respuesta decente a la siguiente pregunta: ¿por qué algunos desarrolladores están tan en contra de las excepciones comprobadas? He tenido numerosas conversaciones, leí cosas en blogs, leí lo que Bruce Eckel tenía que decir (la primera persona que vi habló en contra de ellos).

Actualmente estoy escribiendo un código nuevo y prestando mucha atención a cómo trato con las excepciones. Estoy tratando de ver el punto de vista de la multitud "no nos gustan las excepciones marcadas" y todavía no puedo verlo.

Cada conversación que tengo termina con la misma pregunta sin respuesta ... déjame configurarlo:

En general (de cómo se diseñó Java),

Error es para cosas que nunca se deben atrapar (VM tiene alergia al maní y alguien dejó caer un frasco de maní)RuntimeException es para cosas que el programador hizo mal (el programador salió del final de una matriz)Exception (excepto RuntimeException) es para cosas que están fuera del control del programador (el disco se llena mientras se escribe en el sistema de archivos, se ha alcanzado el límite de manejo de archivos para el proceso y no puede abrir más archivos)Throwable es simplemente el padre de todos los tipos de excepción.

Un argumento común que escucho es que si ocurre una excepción, todo lo que el desarrollador hará es salir del programa.

Otro argumento común que escucho es que las excepciones marcadas hacen que sea más difícil refactorizar el código.

Para el argumento "todo lo que voy a hacer es salir", digo que incluso si está saliendo necesita mostrar un mensaje de error razonable. Si solo cometes errores de manejo, tus usuarios no estarán demasiado contentos cuando el programa salga sin una clara indicación de por qué.

Para la multitud "hace que sea difícil refactorizar", eso indica que no se eligió el nivel adecuado de abstracción. En lugar de declarar que un método arroja una IOException, la IOException debería transformarse en una excepción que sea más adecuada para lo que está sucediendo.

No tengo ningún problema al ajustar Main con catch (Exception) (o en algunos casos catch (Throwable) para asegurar que el programa pueda salir con gracia, pero siempre capto las excepciones específicas que necesito. Hacer eso me permite , como mínimo, muestre un mensaje de error apropiado.

La pregunta a la que la gente nunca responde es esta:

Si arroja subclases RuntimeException en lugar de las subclases Exception, ¿cómo sabe lo que debe atrapar?

Si la respuesta es catch Exception, entonces también está lidiando con los errores del programador de la misma manera que las excepciones del sistema. Eso me parece equivocado

Si detecta Throwable, entonces está tratando las excepciones del sistema y los errores de VM (y similares) de la misma manera. Eso me parece equivocado

Si la respuesta es que solo captura las excepciones que sabe que se lanzan, ¿cómo sabe cuáles se lanzan? ¿Qué sucede cuando el programador X lanza una nueva excepción y se olvida de atraparla? Eso me parece muy peligroso.

Diría que un programa que muestra un seguimiento de pila es incorrecto. ¿Las personas a las que no les gustan las excepciones marcadas no se sienten así?

Entonces, si no le gustan las excepciones marcadas, ¿puede explicar por qué no Y responder la pregunta que no recibe respuesta, por favor?

Edit: no estoy buscando consejos sobre cuándo usar ninguno de los modelos, lo que estoy buscando espor qu people extiende desde RuntimeException porque no les gusta extender desde Exception y / o por qué capturan una excepción y luego vuelven a lanzar una RuntimeException en lugar de agregar lanzamientos a su método. Quiero comprender la motivación para no gustarme las excepciones marcadas.

Respuestas a la pregunta(30)

Su respuesta a la pregunta