prova / cattura e lancia Eccezione

Queste istruzioni in codice sono equivalenti? C'è qualche differenza tra loro?

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

private void calculateArea() {
    try {
        ....do something
    } catch (Exception e) {
        showException(e);
    }
}

Sì, c'è un'enorme differenza: il secondo ingoia l'eccezione (dimostrandolo, è vero), mentre il primo lascerà che si propaghi. ( showExceptionPresumo che questo non lo rilanci.)

Quindi, se chiami il primo metodo e "fai qualcosa" fallisce, il chiamante dovrà gestire l'eccezione. Se chiami il secondo metodo e "fai qualcosa" fallisce, il chiamante non vedrà affatto un'eccezione ... il che generalmente è una cosa negativa, a meno che non showExceptionabbia effettivamente gestito l'eccezione, risolto tutto ciò che era sbagliato e generalmente accertato che calculateAreaha raggiunto il suo scopo.

Sarete in grado di dire questo, perché non è possibile chiamare il primo metodo, senza neanche la cattura Exceptionda soli o dichiarando che il metodo potrebbe gettarlo troppo.

Il primo throws Exception, quindi il chiamante deve gestire il file Exception. Il secondo rileva e gestisce Exceptioninternamente, quindi il chiamante non deve eseguire alcuna gestione delle eccezioni.

Sì. La versione che dichiara throws Exceptionrichiederà il codice chiamante per gestire l'eccezione, mentre la versione che la gestisce esplicitamente non lo farà.

cioè, semplicemente:

performCalculation();

vs. trasferire l'onere della gestione dell'eccezione al chiamante:

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

Sì, c'è molta differenza tra loro. Nel primo blocco di codice, si passa l'eccezione al codice chiamante. Nel secondo blocco di codice lo gestisci tu stesso. Il metodo corretto dipende interamente da ciò che stai facendo. In alcuni casi, si desidera che il codice gestisca l'eccezione (se un file non viene trovato e si desidera crearlo, ad esempio) ma in altri, si desidera che il codice chiamante gestisca l'eccezione (un file non viene trovato e devono specificarne uno nuovo o crearlo).

Anche in generale, non vuoi catturare un'eccezione generica. Invece, ti consigliamo di catturarne solo quelli specifici, come FileNotFoundExceptiono IOExceptionperché possono significare cose diverse.

C'è uno scenario particolare in cui non possiamo usare i lanci, dobbiamo usare try-catch. Esiste una regola "Un metodo sottoposto a override non può generare alcuna eccezione aggiuntiva oltre a quella che la sua classe genitore sta lanciando". Se c'è qualche eccezione extra che dovrebbe essere gestita usando try-catch. Considera questo frammento di codice. C'è una semplice classe base

package trycatchvsthrows;

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

ed è classe derivata:

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
    }
}

Quando dobbiamo chiamare thread.sleep () siamo costretti a usare try-catch, qui non possiamo usare:

 public void show() throws InterruptedException

perché il metodo sottoposto a override non può generare eccezioni aggiuntive.

Presumo che con "identico" ti riferisci al comportamento.

Un comportamento di una funzione può essere determinato da:

1) Valore restituito

2) Eccezioni generate

3) Effetti collaterali (cioè modifiche nell'heap, nel file system, ecc.)

In questo caso, il primo metodo propaga qualsiasi eccezione, mentre il secondo non genera alcuna eccezione selezionata e inghiotte anche la maggior parte delle eccezioni non verificate, quindi il comportamento È diverso.

Tuttavia, se garantisci che "fai qualcosa" non genera mai un'eccezione, il comportamento sarebbe identico (sebbene il compilatore richiederà al chiamante di gestire l'eccezione, nella prima versione)

--modificare--

Dal punto di vista della progettazione delle API, i metodi sono completamente diversi nel loro contratto. Inoltre, non è consigliabile lanciare un'eccezione di classe. Prova a lanciare qualcosa di più specifico per consentire al chiamante di gestire meglio l'eccezione.

Se hai lanciato un'eccezione, il metodo figlio (che sovrascrive questo) dovrebbe gestire l'eccezione

esempio:

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

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

Molte volte si desidera che il chiamante gestisca l'eccezione. Supponiamo che tu abbia il chiamante che chiama un metodo che chiama un altro metodo che chiama un altro metodo, invece di avere ogni metodo che gestisce l'eccezione, puoi semplicemente gestirlo al chiamante. A meno che tu non voglia fare qualcosa in uno dei metodi quando quel metodo fallisce.

Il chiamante di questo metodo dovrà catturare questa eccezione o dichiararla per essere rilanciata nella sua firma del metodo.

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

Nell'esempio di blocco try-catch di seguito. Il chiamante di questo metodo non deve preoccuparsi di gestire l'eccezione poiché è già stato curato.

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

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

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

Questo genera l'eccezione, quindi il chiamante è responsabile della gestione di tale eccezione, ma se il chiamante non gestisce l'eccezione, potrebbe essere assegnata a jvm, il che potrebbe causare la chiusura anomala del programma.

Mentre nel secondo caso:

private void calculateArea() {
    try {
        ....do something
    } catch (Exception e) {
        showException(e);
    }
}

Qui l'eccezione è gestita dal chiamato, quindi non c'è possibilità di interruzione anomala del programma.

Try-catch è l'approccio consigliato.

IMO,

• Genera la parola chiave utilizzata principalmente con le eccezioni verificate per convincere il compilatore ma non garantisce la normale terminazione del programma.

• Genera una parola chiave delegata al
  chiamante (JVM o un altro metodo) la responsabilità della gestione delle eccezioni .

• La parola chiave Throws è richiesta solo per le eccezioni verificate, per le eccezioni non controllate non viene utilizzata la parola chiave Throws.