¿Cuáles son las diferencias entre checked y unchecked exceptions en Java, cómo se debe diseñar correctamente el manejo de errores y qué errores se deben evitar en su uso?

Respuesta

En Java, las excepciones se dividen en checked (comprobadas) y unchecked (no comprobadas).

• Checked exceptions — heredan de Exception, pero no de RuntimeException. El compilador requiere que se manejen explícitamente con try-catch o que se declaren en throws.
• Unchecked exceptions — heredan de RuntimeException. El compilador no exige su manejo obligatorio.

public void readFile(String file) throws IOException { /* ... */ } // checked
public void divide(int a, int b) { int res = a/b; } // unchecked (ArithmeticException)

La principal sutileza es que las checked exceptions se utilizan para situaciones esperadas y recuperables (por ejemplo, errores de entrada/salida), mientras que las unchecked se utilizan para errores de lógica del programa o situaciones críticas de las que no se puede recuperar (por ejemplo, NullPointerException).

Pregunta trampa

Pregunta: ¿Es necesario manejar o declarar en throws una unchecked exception si su método puede lanzarlas?

Respuesta: No. El compilador no requiere que se manejen o declaren las excepciones no recuperables (unchecked). Su manejo es a su discreción; se puede utilizar try-catch, pero más a menudo se permite que "caiga" hasta el manejador global.

public void foo() { throw new IllegalArgumentException(); } // No requiere manejo ni declaración

Ejemplos de errores reales por desconocer las sutilezas del tema

---

Historia

En un proyecto de API bancaria, al manejar errores de entrada/salida se lanzaba RuntimeException en lugar de checked. Como resultado, los clientes no estaban obligados a manejarlas, lo que conducía a un funcionamiento incorrecto en caso de pérdida de conexión con el servidor, y la aplicación "caía" sin informar al usuario.

---

Historia

Un desarrollador declaró un número excesivo de throws Exception en la firma de los métodos (por ejemplo, de bases de datos), lo que obligó a todos los métodos utilizados anteriormente a emplear try-catch o también throws. Esto ensució el código, deterioró la legibilidad y dificultó la refactorización.

---

Historia

En uno de los microservicios, se capturaban todas las excepciones con un catch (Exception e) común. Esto interceptaba también las unchecked exceptions (por ejemplo, NullPointerException), lo que llevaba a una "ignorancia silenciosa" de errores críticos: el servicio funcionaba con datos incorrectos.