gestione eccezioni

[newutente]

Quindi se parliamo di eccezioni unchecked (tutte le sottoclassi di RuntimeException) è sufficiente utilizzare throw quindi lanciando l'eccezione ma senza preoccuparsi di catturarla tramite il try-catch.

Quello che non mi è chiaro però è se c'è differenza tra lanciare una eccezione e gestirla altrove oppure lanciarla e gestirla nel metodo stesso.
Cioè, se questi due frammenti di codice sono equivalenti:

public class Esempio
{
...
    public void aggiungi()
    {
        try
        {
                ...    
            throw new EccezioneException();
        }
        catch (EccezioneException exc)
        {
            ...
        }
    }
...
}

public class Principale
{
    public static void main(String args[])
    {
        Esempio esempio = new Esempio();
        
        try
        {
            esempio.aggiungi();
        }
        catch (EccezioniException exc)
        {
            ...
        }
    }
}



public class Esempio
{
...
    public void aggiungi() throws EccezioneException
    {
        ...    
        throw new EccezioneException();        
    }
...
}

[LeleFT]

Quindi se parliamo di eccezioni unchecked (tutte le sottoclassi di RuntimeException) è sufficiente utilizzare throw quindi lanciando l'eccezione ma senza preoccuparsi di catturarla tramite il try-catch.

Non c'entra nulla.
Le eccezioni unchecked sono eccezioni che il programmatore non è costretto a gestire. Né con try/catch, né con throws. Sono tipi particolari di eccezione che possono essere sollevati a scopo "informativo" per il programmatore dell'applicazione. Se vengono sollevate, il più delle volte significa che il programma non è stato fatto nel modo corretto. Un paio di esempi per chiarire:

- IndexOutOfBoundsException. Se viene sollevata, significa che si è cercato di sforare l'indice di un array: questo, il più delle volte, non significa che il programmatore debba gestire questa eccezione; significa, piuttosto, che il programmatore, prima di fare sciocchezze, dovrebbe controllare la lunghezza dell'array e evitare di sforarlo.

- ArithmeticException. Se viene sollevata significa che il programma sta facendo dei calcoli che non può fare. L'esempio classico è la divisione per 0: il programmatore deve evitare di far fare al programma divisioni per zero, non fargliele fare ed, eventualmente, gestire l'eccezione.

Quello che non mi è chiaro però è se c'è differenza tra lanciare una eccezione e gestirla altrove oppure lanciarla e gestirla nel metodo stesso.
Cioè, se questi due frammenti di codice sono equivalenti:

public class Esempio
{
...
    public void aggiungi()
    {
        try
        {
                ...    
            throw new EccezioneException();
        }
        catch (EccezioneException exc)
        {
            ...
        }
    }
...
}

public class Principale
{
    public static void main(String args[])
    {
        Esempio esempio = new Esempio();
        
        try
        {
            esempio.aggiungi();
        }
        catch (EccezioniException exc)
        {
            ...
        }
    }
}



public class Esempio
{
...
    public void aggiungi() throws EccezioneException
    {
        ...    
        throw new EccezioneException();        
    }
...
}

Da nessuna parte (se non nei libri e, comunque, nel materiale didattico) troverai mai del codice come il primo. Semplicemente perchè non ha alcun senso (dal punto di vista pratico e logico). Ben diverso è il caso del secondo esempio. Lì c'è un metodo che può essere potenzialmente richiamato da più parti del codice (addirittura da codice esterno). Quel metodo sta dicendo: io faccio il mio lavoro, ma se succede qualcosa di anomalo, lo segnalo ma non mi preoccupo di gestirlo. E i motivi per una scelta di questo tipo sono molteplici:

1) Io, metodo, non sono in grado di gestire quel caso particolare
2) Io, metodo, non mi voglio sporcare le mani: non ho una visione sufficientemente ampia del contesto in cui sono stato chiamato, quindi è meglio che sia il chiamante a gestire la cosa (che ha una visione più ampia)
3) Io, metodo, potrei anche gestire l'eccezione, ma forse è meglio non lo faccia perchè il chiamante potrebbe essere interessato a sapere se qualcosa è andato storto.
4) Io, metodo, gestisco solo una parte delle eccezioni che possono insorgere durante il lavoro, ma il resto lo lascio gestire a chi mi chiama (i casi più gravi)
5) Io, metodo, gestisco l'eccezione, ma la rilancio al chiamante con delle informazioni in più, che possono tornargli utili per decidere come gestire il caso.

Se un metodo ha tutte le informazioni per poter gestire un'eccezione, può farlo e non dire nulla a nessuno. Userà un try/catch e finita lì. Altrimenti, se sussistono uno o più dei motivi sopra elencati (non è un elenco esaustivo), semplicemente agirà di conseguenza.


Ciao.

[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)