6

Ho il seguente codiceL'aggiunta di ritorno, infine, nasconde l'eccezione

public static void nocatch() 
{ 
    try 
    { 
     throw new Exception(); 
    } 
    finally 
    { 

    } 
} 

che dà l'errore

Exception in thread "main" java.lang.Error: Unresolved compilation problem: 
Unhandled exception type CustomException 

Che è come previsto, ma l'aggiunta di una dichiarazione return nel blocco finally rende l'errore vai via

public static void nocatch() 
{ 
    try 
    { 
     throw new Exception(); 
    } 
    finally 
    { 
     return; //makes the error go away! 
    } 
} 

Qualcuno può spiegarmi che cos'è sta succedendo? e perché l'errore scompare?

Nota: Ho scritto questo codice esclusivamente per scopi sperimentali!

+1

Post correlati: [prova a bloccare definitivamente l'esecuzione] (http://stackoverflow.com/q/18131447/1679863). Anche se questo non parla dell'eccezione, ma il ragionamento per questo è lo stesso. –

+1

Side-note: non provare a eseguire codice che non viene compilato. Non c'è davvero alcun vantaggio nel farlo. Parla dell'errore in fase di compilazione, piuttosto che dell'eccezione ottenuta dal codice in esecuzione che non è stato compilato per iniziare. –

+0

@JonSkeet Volevo solo segnalare l'errore che ha causato, motivo per cui ho eseguito il codice. – codeMan

risposta

7

L'errore scompare perché il codice è ora valido. (Non bello, ma valido.)

Se un blocco finally ha una semplice istruzione return;, l'istruzione generale try/catch/finally o try/finally non può generare eccezioni, quindi non è necessario dichiarare che è possibile lanciare un'eccezione.

Nel codice originale, il blocco try potrebbe (beh, sarà) lanciare Exception (o CustomException nel codice vero e proprio, a quanto pare) - e questo è un eccezione controllata, il che significa che dovete possibile prenderlo o dichiarare che il metodo potrebbe lanciarlo.

+0

Mi chiedo se il comportamento di uccisione delle eccezioni dei ritorni nei blocchi di "finally" di Java fosse una funzione fornita intenzionalmente, o se Gosling et al. semplicemente non pensava che valesse la pena di impedire? Spero che sia stato il primo, anche se sarebbe stato il caso per Gosling et al. avere documentato un "requisito non forzato" che un blocco 'finally' può * solo * legittimamente ritornare nei casi in cui il codice sa che nessuna eccezione potrebbe essere in sospeso (ad esempio perché un flag è stato impostato come ultima operazione in un' try' o blocco 'catch'). – supercat

0

Come per il javadoc ...

The finally block always executes when the try block exits. 
This ensures that the finally block is executed even if an unexpected exception occurs. 

Così il vostro codice sta facendo correttamente ora.

+0

Puoi aggiungere un link? – DataDino

+1

@DataDino https://docs.oracle.com/javase/tutorial/essential/exceptions/finally.html –