allora le eccezioni in java si gestiscono tramite le parole try catch finally trow e trows...qual è la differenza tra trows-trow e try-catch-finaly??
allora le eccezioni in java si gestiscono tramite le parole try catch finally trow e trows...qual è la differenza tra trows-trow e try-catch-finaly??
<´¯)(¯`¤._)(¯`»ANDREA«´¯)(_.¤´¯)(¯`>
"The answer to your question is: welcome to tomorrow"
mmm di guide ne ho lette molte...cercavo qualcuno che me lo spiegasse con poche parole e molta sostanza...Originariamente inviato da c_nicola
allora le eccezioni in java si gestiscono tramite le parole try catch finally trow e trows...qual è la differenza tra trows-trow e try-catch-finaly??
try-catch-finally:
throw:codice:try { //qui testi del codice che può sollevare eccezzioni } catch (TipoEccezione e) { //qui catturi le eccezioni di tipo "TipoEccezione" } finally { //questo blocco di codice viene sempre eseguito }
throws:codice:throw new Exception(); //lanci un eccezione
Il metodo throws in genere consente di evitare il classico blocco try-catch-finally all'interno del corpo del metodo, in quanto l'eccezione non gestita verrà risollevata alla funzione che invocherà il metodo stesso.codice:public void funzione() throws Eccezione1, Eccezione2 { //Indichi che il metodo "funzione" risolleva due tipi di eccezione, rispettivamente Eccezione1 e Eccezione2 }
P.S. Le "poche parole" non vanno di pari passo con la "molta sostanza" quindi ti consiglio di vedertela una guida perchè se come tu dici ne hai già lette diverse non puoi ignorare il significato di questi concetti basilari dell'Exception Handling.
![]()
Quindi da come ho capito posso usare Trow e trows al posto di try catch finally?Originariamente inviato da M@P
try-catch-finally:
throw:codice:try { //qui testi del codice che può sollevare eccezzioni } catch (TipoEccezione e) { //qui catturi le eccezioni di tipo "TipoEccezione" } finally { //questo blocco di codice viene sempre eseguito }
throws:codice:throw new Exception(); //lanci un eccezione
Il metodo throws in genere consente di evitare il classico blocco try-catch-finally all'interno del corpo del metodo, in quanto l'eccezione non gestita verrà risollevata alla funzione che invocherà il metodo stesso.codice:public void funzione() throws Eccezione1, Eccezione2 { //Indichi che il metodo "funzione" risolleva due tipi di eccezione, rispettivamente Eccezione1 e Eccezione2 }
P.S. Le "poche parole" non vanno di pari passo con la "molta sostanza" quindi ti consiglio di vedertela una guida perchè se come tu dici ne hai già lette diverse non puoi ignorare il significato di questi concetti basilari dell'Exception Handling.
![]()
No, dipende ...Originariamente inviato da c_nicola
Quindi da come ho capito posso usare Trow e trows al posto di try catch finally?
throw serve per "lanciare", throws per "dichiarare" (il senso del dichiarare è per le eccezioni "checked") mentre try/catch (con o senza finally) serve per "provare" a fare qualcosa potendo catturare la/e eccezione/i.
Andrea, andbin.dev – Senior Java developer – SCJP 5 (91%) • SCWCD 5 (94%)
java.util.function Interfaces Cheat Sheet — Java Versions Cheat Sheet
Allora pe quanto riguarda try catch io ho visto sempre il classico esempio della divisione per 0...quella non è un'eccezione gestibile anche con throw e throws? Non capisco quando si una l'uno e quando l'altro...Originariamente inviato da andbin
No, dipende ...
throw serve per "lanciare", throws per "dichiarare" (il senso del dichiarare è per le eccezioni "checked") mentre try/catch (con o senza finally) serve per "provare" a fare qualcosa potendo catturare la/e eccezione/i.
Ma sono cose diverse!! Ripeto: che throw è per lanciare. Certe eccezioni possono essere lanciate direttamente dalla JVM ma ovviamente anche il programmatore può definire eccezioni e lanciarle esplicitamente. Questa è una cosa.Originariamente inviato da c_nicola
Allora pe quanto riguarda try catch io ho visto sempre il classico esempio della divisione per 0...quella non è un'eccezione gestibile anche con throw e throws? Non capisco quando si una l'uno e quando l'altro...
Altra cosa è dichiarare, con throws, che un metodo può lanciare certe eccezioni. E il senso del dichiarare è per le eccezioni "checked" piuttosto che per le "unchecked".
Andrea, andbin.dev – Senior Java developer – SCJP 5 (91%) • SCWCD 5 (94%)
java.util.function Interfaces Cheat Sheet — Java Versions Cheat Sheet
E sono cose diverse...e la differenza qual è? Il catch serve per "catturare" delle eccezioni che sicuramente ci saranno?Originariamente inviato da andbin
Ma sono cose diverse!! Ripeto: che throw è per lanciare. Certe eccezioni possono essere lanciate direttamente dalla JVM ma ovviamente anche il programmatore può definire eccezioni e lanciarle esplicitamente. Questa è una cosa.
Altra cosa è dichiarare, con throws, che un metodo può lanciare certe eccezioni. E il senso del dichiarare è per le eccezioni "checked" piuttosto che per le "unchecked".![]()
![]()
![]()
![]()
Partiamo dal throws e dalla differenza checked/unchecked. Per le eccezioni checked vale la regola che si dice "handle or declare". Il programmatore non può "ignorare" una eccezione checked, deve fare "qualcosa" nel codice che scrive, che sia gestire (=catturare e fare di conseguenza) o dichiarare la eccezione ma qualcosa deve fare.Originariamente inviato da c_nicola
E sono cose diverse...e la differenza qual è? Il catch serve per "catturare" delle eccezioni che sicuramente ci saranno?![]()
![]()
![]()
![]()
Un metodo A invoca un metodo B che dichiara con throws di poter lanciare IOException (checked). Chi scrive il metodo A deve fare qualcosa con questa IOException. Può mettere in A un try/catch, nel try invoca B e nel catch gestisce la eccezione (stampa messaggio, log, altro ecc.... quello che vuole).
Oppure a sua volta dichiarare che A può lanciare IOException. Questo vuol dire che IOException può uscire da B e può anche uscire da A. E in sostanza la regola del gestire-o-dichiarare semplicemente si è spostata più "sopra" perché chi a sua volta invocherà A si dovrà porre la stessa questione: gestisco o dichiaro.
Il throws serve appunto per "forzare" il fatto di dover prendere in considerazione una eccezione checked.
Per quelle unchecked non c'è questa regola: non si è obbligati né a dichiararle, né a gestirle.
Andrea, andbin.dev – Senior Java developer – SCJP 5 (91%) • SCWCD 5 (94%)
java.util.function Interfaces Cheat Sheet — Java Versions Cheat Sheet