Preparare la certificazione Java Programmer OCPJP7: Eccezioni e asserzioni

EXCEPTIONS & ASSERTIONS

E’ possibile recuperare l’elenco delle chiamate nello stacktrace, quando si verifica un’eccezione, tramite il metodo getStackTrace()

Tale metodo ritorna un array di StackTraceElement che è ad esempio possibile scorrere con un loop for:
for(StackTraceElement ste: e.getStackTrace())

In un blocco multi-catch NON si possono combinare insieme due eccezioni che appartengono alla stessa gerarchia.
La scelta se utilizzare gli handler delle eccezioni come blocchi in cascata oppure un blocco multi-catch dipende da aspetti di design e dalle funzionalità:

Le eccezioni vengono scatenate per motivi simili oppure in condizioni molto diverse tra loro? Il codice di gestione delle eccezioni è simile oppure molto diverso tra le varie eccezioni?
Se la risposta ad entrambe le domande è che sono simili, allora si può pensare di utilizzare un blocco multi-catch.

E’ possibile fare il throw di una eccezione passandogli come parametro un’altra eccezione. In questo caso di parla di chained exceptions.
Con il metodo getCause() di un’eccezione si ritorna l’oggetto Throwable che eventualmente rappresenta l’eccezione chained con la quale l’eccezione corrente è stata creata.

Se non c’è una chained exception di partenza con cui l’eccezione è stata creata, il metodo getCause() ritorna null.

Il metodo initCause(Throwable causeException) serve per settare la chained-exception di un’eccezione qualora non sia già stata settata nella istanziazione dell’eccezione stessa.
Se la causa è già stata valorizzata e si invoca comunque il metodo initCause, si ottiene una IllegalStateException.
In uno statement try-with-resources si possono includere più statement relative all’acquisizione di risorse.

Nel try-with-resources si possono solo utilizzare come risorse oggetti di classi che implementano l’interfaccia AutoCloseable.

L’interfaccia Closeable estende l’interfaccia AutoCloseable (e non viceversa), per cui anche le classi che estendono Closeable possono essere utilizzate.

Le variabili definite nella dichiarazione di un try-with-resources NON possono essere riassegnate nel body dello statement. Questo per essere sicuri che le risorse rilasciate automaticamente siano effettivamente quelle riservate tramite il try-with-resources.
NON bisogna invocare esplicitamente il metodo close() su risorse allocate tramite il try-with-resources. In alcuni casi questo può dare dei problemi, perché alcuni tipi di risorse ignorano eventuali chiamate doppie, ma altri scatenano invece delle eccezioni.
Le clausole throws si possono mettere anche nella definizione dei metodi delle interfacce e nei metodi astratti delle classi abstract.
I blocchi di inizializzazione statici NON possono scatenare nessuna checked exception.
I blocchi di inizializzazione non-statici possono scatenare delle checked exception. In questo caso TUTTI i costruttori devono dichiarare che possono scatenare queste eccezioni.
Se un metodo è definito in due o più interfacce nelle quali dichiara di generare tipi diversi di eccezioni, il metodo concreto implementato deve dichiarare tutte le eccezioni previste dal metodo nelle diverse interfacce.
Un metodo di override può dichiarare delle RunTimeExceptions che nel metodo della classe base non sono dichiarate, perché le eccezioni di runtime non devono essere gestite dal chiamante.
Nel multi catch si deve mettere solo un nome per l’eccezione che viene catturata e non uno per ogni possibile eccezione definita nel multi catch:

A RunTime il tipo dell’eccezione viene determinate dinamicamente in base al tipo reale dell’oggetto, per cui, anche se l’oggetto viene referenziato con una reference di una sovraclasse nel catch viene valutato in base al suo vero tipo.
Se nel codice c’è un assert false e le asserzioni sono abilitate ( tramite il flag –ea al lancio dell’applicazione) viene generato un AssertionError

Quindi, nel caso ci siano più catch, quello che cattura l’errore è: catch(Error ae) { … }

Dede Blog: just another Software Development Engineer