¿Por qué es necesario "throws Exception" al llamar a una función?

class throwseg1
{
    void show() throws Exception
    {
        throw new Exception("my.own.Exception");
    }

    void show2() throws Exception  // Why throws is necessary here ?
    {
        show();
    }

    void show3() throws Exception  // Why throws is necessary here ?
    {
        show2();
    }

    public static void main(String s[]) throws Exception  // Why throws is necessary here ?
    {
        throwseg1 o1 = new throwseg1();
        o1.show3();
    }
}

¿Por qué los informes del compilador que los métodos show2(), show3()y main()tener

excepción no informada Excepción que debe detectarse o declararse para ser lanzada

cuando elimino throws Exceptionde estos métodos?

En Java, como ya sabrá, las excepciones se pueden clasificar en dos: una que necesita la throwscláusula o debe manejarse si no especifica una y otra que no. Ahora, vea la siguiente figura:

En Java, puede lanzar cualquier cosa que amplíe la Throwableclase. Sin embargo, no es necesario especificar una throwscláusula para todas las clases. Específicamente, las clases que son o bien una Erroro RuntimeExceptiono cualquiera de las subclases de estos dos. En su caso, Exceptionno es una subclase de Erroro RuntimeException. Por lo tanto, es una excepción marcada y debe especificarse en la throwscláusula, si no maneja esa excepción en particular. Por eso necesitabas la throwscláusula.

Desde el tutorial de Java :

Una excepción es un evento, que ocurre durante la ejecución de un programa, que interrumpe el flujo normal de las instrucciones del programa.

Ahora, como sabe, las excepciones se clasifican en dos: marcadas y no marcadas. ¿Por qué esta clasificación?

Excepción marcada: Se utilizan para representar problemas que se pueden recuperar durante la ejecución del programa. Por lo general, no son culpa del programador. Por ejemplo, un archivo especificado por el usuario no es legible, o no hay conexión de red disponible, etc., en todos estos casos, nuestro programa no necesita salir, sino que puede tomar acciones como alertar al usuario, o entrar en una reserva. mecanismo (como trabajar sin conexión cuando la red no está disponible), etc.

Excepciones sin marcar : nuevamente se pueden dividir en dos: Errores y Excepciones en tiempo de ejecución. Una de las razones por las que no deben estar marcados es que son numerosos en número y, si se requiere manejarlos, saturará nuestro programa y reducirá su claridad. La otra razón es:

• Excepciones en tiempo de ejecución: generalmente ocurren debido a una falla del programador. Por ejemplo, si ArithmeticExceptionocurre una división por cero o ocurre una ArrayIndexOutOfBoundsException, es porque no somos lo suficientemente cuidadosos en nuestra codificación. Suelen ocurrir debido a algunos errores en la lógica de nuestro programa. Por lo tanto, deben borrarse antes de que nuestro programa entre en modo de producción. Están desmarcados en el sentido de que nuestro programa debe fallar cuando se produzca, para que los programadores podamos resolverlo en el momento del desarrollo y testeo.

• Errores: Los errores son situaciones de las que normalmente el programa no puede recuperarse. Por ejemplo, si StackOverflowErrorocurre un , nuestro programa no puede hacer mucho, como aumentar el tamaño de la pila de llamadas a funciones del programa. O si OutOfMemoryErrorocurre una , no podemos hacer mucho para aumentar la cantidad de RAM disponible para nuestro programa. En tales casos, es mejor salir del programa. Es por eso que se hacen sin control.

Para obtener información detallada, consulte:

• Excepciones no controladas: la controversia
• El requisito de capturar o especificar

Java requiere que maneje o declare todas las excepciones. Si no está manejando una excepción usando un bloque try / catch, debe declararse en la firma del método.

Por ejemplo:

class throwseg1 {
    void show() throws Exception {
        throw new Exception();
    }
}

Debe escribirse como:

class throwseg1 {
    void show() {
        try {
            throw new Exception();
        } catch(Exception e) {
            // code to handle the exception
        }
    }
}

De esta manera puede deshacerse de la declaración "throws Exception" en la declaración del método.

Exceptiones una clase de excepción comprobada. Por lo tanto, cualquier código que llame a un método que declare que throws Exceptiondebe manejarlo o declararlo.

La throws Exceptiondeclaración es una forma automatizada de realizar un seguimiento de los métodos que pueden generar una excepción por razones anticipadas pero inevitables. La declaración suele ser específica sobre el tipo o tipos de excepciones que se pueden generar, como throws IOExceptiono throws IOException, MyException.

Todos tenemos o eventualmente escribiremos código que se detiene inesperadamente e informa una excepción debido a algo que no anticipamos antes de ejecutar el programa, como la división por cero o el índice fuera de los límites. Dado que el método no esperaba los errores, no podían "detectarse" ni manejarse con una cláusula try catch. Cualquier usuario desprevenido del método tampoco conocería esta posibilidad y sus programas también se detendrían.

Cuando el programador sabe que pueden ocurrir ciertos tipos de errores pero le gustaría manejar estas excepciones fuera del método, el método puede "lanzar" uno o más tipos de excepciones al método de llamada en lugar de manejarlas. Si el programador no declara que el método (podría) lanzar una excepción (o si Java no tiene la capacidad de declararlo), el compilador no podría saberlo y dependerá del futuro usuario del método conocerlo, captura y maneja cualquier excepción que el método pueda generar. Dado que los programas pueden tener muchas capas de métodos escritos por muchos programas diferentes, resulta difícil (imposible) realizar un seguimiento de los métodos que pueden generar excepciones.

Aunque Java tiene la capacidad de declarar excepciones, aún puede escribir un nuevo método con excepciones no controladas y no declaradas, y Java lo compilará y podrá ejecutarlo y esperar lo mejor. Lo que Java no le permitirá hacer es compilar su nuevo método si usa un método que ha sido declarado como lanzando excepciones, a menos que maneje las excepciones declaradas en su método o declare que su método arroja lo mismo excepción (es) o si hay varias excepciones, puede manejar algunas y lanzar el resto.

Cuando un programador declara que el método genera un tipo específico de excepción, es solo una forma automatizada de advertir a otros programadores que utilizan el método de que es posible una excepción. Luego, el programador puede decidir manejar la excepción o pasar la advertencia declarando que el método de llamada también lanza la misma excepción. Dado que el compilador ha sido advertido de que la excepción es posible en este nuevo método, puede verificar automáticamente si los futuros llamadores del nuevo método manejan la excepción o la declaran y obligan a que suceda una u otra.

Lo bueno de este tipo de solución es que cuando el compilador informa Error: Unhandled exception type java.io.IOException, da el archivo y el número de línea del método que se declaró para lanzar la excepción. A continuación, puede optar por simplemente pasar la pelota y declarar que su método también "lanza IOException". Esto se puede hacer hasta el método principal, donde luego haría que el programa se detuviera e informara la excepción al usuario. Sin embargo, es mejor detectar la excepción y tratarla de una manera agradable, como explicarle al usuario lo que ha sucedido y cómo solucionarlo. Cuando un método detecta y maneja la excepción, ya no tiene que declarar la excepción. La pelota se detiene allí, por así decirlo.

package javaexception;


public class JavaException {
   void show() throws Exception
    {
        throw new Exception("my.own.Exception");
    }

void show2() throws Exception  // Why throws is necessary here ?
{
    show();
}

void show3() throws Exception  // Why throws is necessary here ?
{
    show2();
}
public static void main(String[] args) {

   JavaException a = new JavaException();

   try{
   a.show3();
   }catch(Exception e){
       System.out.println(e.getMessage());
   }
}

Solo pequeños cambios en su programa. Lo que parece ser malinterpretado por muchos con respecto al problema principal, es que cada vez que lanza una excepción, debe manejarla, no es necesario en el mismo lugar (por ejemplo, el método show1,2,3 en su programa) pero debe al principio el método de llamada dentro del 'principal'. en una palabra, hay 'lanzar', debe haber 'atrapar / intentar', incluso si no es el mismo método donde ocurre la excepción.

void show() throws Exception
{
    throw new Exception("my.own.Exception");
}

Como hay una excepción marcada en el método show (), que no se maneja en ese método, usamos la palabra clave throws para propagar la excepción.

void show2() throws Exception //Why throws is necessary here ?
{
show();
}

Dado que está utilizando el método show () en el método show2 () y ha propagado la excepción, al menos debería manejar aquí. Si no está manejando la excepción aquí, entonces está usando la palabra clave throws. Entonces esa es la razón para usar la palabra clave throws en la firma del método.

Si propaga la excepción declarando la directiva throws en la firma del método actual, entonces en algún lugar de la línea o pila de llamadas se debe usar una construcción try / catch para manejar la excepción.

Básicamente, si no está manejando la excepción en el mismo lugar donde la está lanzando, entonces puede usar "throws exception" en la definición de la función.