gestione eccezioni

[newutente]

Forse ho capito.
Cerco di riassumere sommariamente i concetti:

- le eccezioni vanno gestite dove vengono invocati i metodi e vanno sollevate nel metodo stesso (secondo esempio fatto prima).

- quando si crea un oggetto l'eccezione va gestita (blocco try-catch) nel costruttore

- la parola throws sta ad indicare che in quel metodo sarà lanciata (throw) una eccezione ma sarà gestita (blocco try-catch) altrove (nel metodo che chiama il metodo in questione - es. nel main)

- SOLO nel caso di eccezioni unchecked (tutto le sottoclassi di RuntimeException) si può tranquillamente lanciare (throw) l'eccezione ma senza la necessità di gestirla (blocco try-catch) quindi non serve mettere throws.
Volendo il programmatore può decidere comunque di gestire l'eccezione e lo può fare liberamente nel metodo stesso, quindi con blocco try-catch, oppure indicando throws e inserendo il blocco try-catch altrove (nel metodo che chiama il metodo in questione - es. nel main).

Spero di non aver sbagliato.

[LeleFT]

- le eccezioni vanno gestite dove vengono invocati i metodi e vanno sollevate nel metodo stesso (secondo esempio fatto prima).

Non necessariamente. Dipende sempre da ciò che si può/vuole fare e dal tipo di eccezione.
Le eccezioni unchecked possono essere gestite oppure no. A discrezione del programmatore
Le eccezioni checked devono essere gestite in qualche modo: o si gestiscono con un try/catch o si demanda la gestione al chiamante con un throws sulla firma del metodo.
La seconda parte di questa frase ha poco senso: tutte le eccezioni vengono sollevate nel punto in cui c'è un throw (che sia codice del programmatore o della JVM).

- quando si crea un oggetto l'eccezione va gestita (blocco try-catch) nel costruttore

Non necessariamente. Anche qui, sta al programmatore decidere se nel costruttore di un oggetto il contesto è sufficientemente chiaro da poter gestire eventuali eccezioni oppure no. Anche i costruttori, come i metodi, possono sollevare eccezioni e, nel caso di eccezioni checked, le dichiarano con la clausola throws.

- la parola throws sta ad indicare che in quel metodo sarà lanciata (throw) una eccezione ma sarà gestita (blocco try-catch) altrove (nel metodo che chiama il metodo in questione - es. nel main)

Ni. La clausola throws significa che quel metodo può sollevare quel tipo di eccezioni (le eccezioni, lo dice il nome, sono qualcosa di "eccezionale", non la regola). Chi usa quel metodo deve (nel caso di eccezioni checked) provvedere al trattamento: con try/catch o con altro throws.

- SOLO nel caso di eccezioni unchecked (tutto le sottoclassi di RuntimeException) si può tranquillamente lanciare (throw) l'eccezione ma senza la necessità di gestirla (blocco try-catch) quindi non serve mettere throws.
Volendo il programmatore può decidere comunque di gestire l'eccezione e lo può fare liberamente nel metodo stesso, quindi con blocco try-catch, oppure indicando throws e inserendo il blocco try-catch altrove (nel metodo che chiama il metodo in questione - es. nel main).

Sì.

Ciao.

[valia]

Non necessariamente. Anche qui, sta al programmatore decidere se nel costruttore di un oggetto il contesto è sufficientemente chiaro da poter gestire eventuali eccezioni oppure no. Anche i costruttori, come i metodi, possono sollevare eccezioni e, nel caso di eccezioni checked, le dichiarano con la clausola throws.

in realtà con il costruttore bisognerebbe fare attenzione e vedere se non è possibile fare in altro modo.
Intanto l'oggetto non è correttamente inizializzato, che fai continui? vai in eccezione? L'oggetto è pronto per essere finalizzato, ma quando interviene il gc?

Dal punto di vista della sicurezza, queste possono essere anche back door (è sicuramente pronto per il gc, implementi finalize e fai quello che ti pare).

In generale quindi per le eccezioni dal costruttore chiediti se è davvero necessario averle (e in caso prendi opportuni provvedimenti per garantire integrità e sicurezza)