try/catch versus throws Excepción

Question

¿Estas declaraciones de código son equivalentes? ¿Hay alguna diferencia entre ellos?

private void calculateArea() throws Exception { 
     ....do something 
    } 

---

private void calculateArea() { 
     try { 
      ....do something 

     } catch (Exception e) { 
      showException(e); 
     } 
    } 

Answer 1

Sí, hay una gran diferencia - este último se traga la excepción (mostrando que, sin duda), mientras que el primero será dejar que se propague. (Supongo que showException no lo vuelve a lanzar.)

Si llama al primer método y "hacer algo" falla, la persona que llama tendrá que manejar la excepción. Si llama al segundo método y "hacer algo" falla, entonces la persona que llama no verá una excepción ... lo cual es generalmente algo malo, a menos que showException haya genuinamente haya manejado la excepción, solucionado lo que estaba mal y en general, se aseguró de que calculateArea haya logrado su propósito.

Usted será capaz de decir esto, porque no se puede llamar el primer método, sin ya sea la captura de Exception mismo o declarar que su método podría tirar también.

Answer 2

Sí. La versión que declara throws Exception requerirá que el código de llamada maneje la excepción, mientras que la versión que maneja explícitamente no lo hará.

es decir, simplemente:

performCalculation(); 

frente a mover la carga de manejar la excepción a la persona que llama:

try { 
    performCalculation(); 
catch (Exception e) { 
    // handle exception 
} 

Answer 3

Primero uno throws Exception, por lo que la persona que llama tiene que manejar el Exception. El segundo captura y maneja Exception internamente, por lo que la persona que llama no tiene que hacer ningún manejo de excepción.

Answer 4

Sí, hay una gran diferencia entre ellos. En el primer bloque de código, pasa la excepción al código de llamada. En el segundo bloque de código lo manejas tú mismo. El método correcto depende completamente de lo que esté haciendo. En algunos casos, desea que su código maneje la excepción (si no se encuentra un archivo y desea crearlo, por ejemplo) pero en otros, desea que el código de llamada maneje la excepción (no se encuentra un archivo). y necesitan especificar uno nuevo o crearlo).

Hablando en general también, no desea detectar una excepción genérica. En su lugar, querrá capturar solo los específicos, como FileNotFoundException o IOException porque pueden significar cosas diferentes.

Answer 5

Supongo que por "idéntico" se refiere al comportamiento.

Un comportamiento de una función se puede determinar por:

1) Valor devuelto

2) excepciones lanzadas

3) efectos secundarios (i.e cambios en el montón, sistema de archivos, etc.)

En este caso, el primer método propaga cualquier excepción, mientras que el segundo arroja ninguna excepción marcada, y se traga también la mayoría de las excepciones no verificadas, por lo que el comportamiento ES diferente.

Sin embargo, si usted garantiza que "hacer algo" nunca se produce una excepción, entonces el comportamiento sería idéntico (aunque el compilador requerirá la persona que llama para manejar la excepción, en la primera versión)

--edit -

Desde el punto de vista del diseño de la API, los métodos son completamente diferentes en su contrato. Además, throwing class Exception no es recomendable. Intente arrojar algo más específico para permitir que la persona que llama maneje mejor la excepción.

Answer 6

Hay un caso particular en el que no podemos usar throws, tenemos que usar try-catch. Existe una regla "Un método anulado no puede arrojar ninguna excepción adicional a la que está lanzando su clase principal". Si hay alguna excepción adicional que deba manejarse con try-catch. Considere este fragmento de código. Hay una sencilla clase base

package trycatchvsthrows; 

public class Base { 
    public void show() 
    { 
     System.out.println("hello from base"); 
    } 
} 

y se deriva de clase:

package trycatchvsthrows; 

public class Derived extends Base { 

    @Override 
    public void show() { 
     // TODO Auto-generated method stub 
     super.show(); 

     Thread thread= new Thread(); 
     thread.start(); 
     try { 
      thread.sleep(100); 
     } catch (InterruptedException e) { 
      // TODO Auto-generated catch block 
      e.printStackTrace(); 
     } 

     // thread.sleep(10); 
     // here we can not use public void show() throws InterruptedException 
     // not allowed 
    } 
} 

Cuando tenemos que llamar Thread.Sleep() nos vemos obligados a utilizar try-catch, aquí no podemos utilizar :

public void show() throws InterruptedException 

porque el método reemplazado no puede arrojar excepciones adicionales.

Answer 7

El llamante de este método deberá detectar esta excepción o declarar que se vuelve a lanzar en su firma de método.

private void calculateArea() throws Exception { 
     // Do something 
    } 

En el ejemplo del bloque try-catch a continuación. La persona que llama de este método no tiene que preocuparse por manejar la excepción, ya que ya se ha solucionado.

private void calculateArea() { 
    try { 
     // Do something 

    } catch (Exception e) { 
     showException(e); 
    } 
} 

Answer 8

Muchas veces desea que la persona que llama maneje la excepción. Supongamos que hace que la persona que llama invoque un método que llama a otro método que llama a otro método, en lugar de que cada método maneje la excepción, puede manejarlo en la persona que llama. A menos que desee hacer algo en uno de los métodos cuando ese método falla.

Answer 9

Si inició una excepción, el método niño (que anula este) debe manejar la excepción

ejemplo:

class A{ 
public void myMethod() throws Exception{ 
//do something 
} 
} 

A a=new A(); 
try{ 
a.myMethod(); 
}catch Exception(e){ 
//handle the exception 
} 

No