¿Por qué método que llama a otro que lanza RuntimeException necesita instrucción de retorno?

AdnanM91:

¿Por inalcanzable declaración no se identifica mediante javac?

public int directThrow(){
     throw new RuntimeException();
    //Compiles fine
}

public int indirectThrow(){
    directThrow();
    // Missing Return Statement error
}

barredora:

El compilador simplemente no está diseñado para analizar el código que profundamente.

Para directThrow, las miradas del compilador en ella y dice, "Veo que tiene una sentencia throw, por lo que el método terminará bruscamente aquí, no hay necesidad de una instrucción de retorno entonces!"

Para indirectThrow, las miradas del compilador en ella y dice: "Sólo veo una llamada al método. Hey programador! Se necesita una instrucción de retorno aquí!"

El compilador no se fija en lo que directThrowhace en realidad. Creo que esto es bastante razonable, ya que el beneficio de analizar lo que cada método se llama a sí es muy pequeña, en comparación con el costo de un mayor tiempo de compilación. Piense en lo que el compilador tiene que comprobar para asegurarse de que directThrowsiempre habrá una excepción. La cosa más importante es, ¿es reemplazado por algo? Se puede incluso comprobar que? Se puede incluso asegurarse de que ninguna clase en el futuro será subclase la clase y anular ese método (dar a su clase y directThrowson a la vez no final)?

Si tiene alguna complicada lógica excepción de lanzamiento que desea extraer en un método, se puede extraer en un método que devuelve el Exception:

private Exception someComplicatedLogicThatGivesAnException() { ... }

public void foo() {
    if (...) {
        throw someComplicatedLogicThatGivesAnException();
    }
}