¿Por qué se permite la captura de excepciones verificadas para el código que no arroja excepciones?

Java 7 introdujo una comprobación de tipos de excepción más inclusiva.

Sin embargo, en Java SE 7, puede especificar los tipos de excepción FirstException y SecondException en la cláusula throws en la declaración del método rethrowException. El compilador Java SE 7 puede determinar que la excepción lanzada por la instrucción throw e debe haber venido del bloque try, y las únicas excepciones lanzadas por el bloque try pueden ser FirstException y SecondException.

Esto passage habla de un bloque try que lanza específicamente FirstException y SecondException; a pesar de que el bloque catch lanza Exception, el método solo necesita declarar que lanza FirstException y SecondException, no Exception:

public void rethrowException(String exceptionName)
 throws FirstException, SecondException {
   try {
     // ...
   }
   catch (Exception e) {
     throw e;
   }
 }

Esto significa que el compilador puede detectar que los únicos tipos de excepción posibles lanzados en test son Error s o RuntimeException s, ninguno de los cuales necesita ser capturado. Cuando throw e;, puede decir, incluso cuando el tipo estático es Exception, que no necesita ser declarado o re-atrapado.

Pero cuando lo lanzas a Exception, esto pasa por alto esa lógica. Ahora el compilador lo trata como un Exception ordinario que necesita ser capturado o declarado.

La razón principal para agregar esta lógica al compilador era permitir al programador especificar solo subtipos específicos en la cláusula throws al repensar un Exception general que captura esos subtipos específicos. Sin embargo, en este caso, le permite capturar un general Exception y no tener que declarar cualquier exception in a throws clause, because no specific types that can be thrown are checked exceptions.

El problema aquí es que las limitaciones de excepción marcadas/no marcadas afectan lo que su código está permitido para lanzar, no lo que está permitido para atrapar. Si bien todavía puedes atrapar cualquier tipo de Exception, los únicos que puedes lanzar de nuevo son los que no están controlados. (Esta es la razón por la que convertir su excepción sin marcar en una excepción marcada rompe su código.)

La captura de una excepción no controlada con Exception es válida, porque las excepciones no controladas (a. k. a. RuntimeException s) son una subclase de Excepción, y sigue las reglas de polimorfismo estándar; no convierte la excepción atrapada en un Exception, al igual que almacenar un String en un Object no convierte la String en un Object. Polimorfismo significa que una variable que puede contener un Object puede contener cualquier cosa derivada de Object (tales como String). Del mismo modo, como Exception es la superclase de todos los tipos de excepción, una variable de tipo Exception puede contener cualquier clase derivada de Exception, sin girar el objeto en y Exception. Considere esto:

import java.lang.*;
// ...
public String iReturnAString() { return "Consider this!"; }
// ...
Object o = iReturnAString();

A pesar de que el tipo de la variable es Object, o todavía almacena un String, ¿no es así? Del mismo modo, en su código:

try {
    safeMethod();
} catch (Exception e) { // catching checked exception
    throw e; // so I can throw... a checked Exception?
}

Lo que esto significa es en realidad "atrapar cualquier cosa compatible con la clase Exception (es decir, Exception y cualquier cosa derivada de ella)."Lógica similar se utiliza en otros lenguajes, también; por ejemplo, en C++, catching a std::exception también atrapará std::runtime_error, std::logic_error, std::bad_alloc, cualquier excepción creada por el usuario correctamente definida, y así sucesivamente, porque todos derivan de std::exception.

Tl; dr: No estás capturando excepciones marcadas, estás capturando cualquier excepciones. La excepción solo se convierte en una excepción marcada si la convierte en un tipo de excepción marcada.