eccezioni....qualcosa da chiarire

[blubossa]

Ciao,
sto studiano le eccezioni e vorrei chiarire qualche argomento...

generalmente ad un metodo che può scatenare un'eccezione aggiungo alla firma del metodo
trowhs ArithmetiException.....

...si può aggiungere anche alla classe throws.....?

se faccio n override i un metodo che nella classe padre utiizza throws... devo aggiungere throws anche nl metodo di override?

...spero di essermi spiegato....

bb

[valia]

alla classe throws? throws si riferisce ai metodi, non alla classe.

[blubossa]

...ok alla classe non si mette nessun throws!!!

io chiedevo se faccio un overridnig di un metodo che ha throw tipoEccezione devo rimettere throw anche al nuovo metodo??

bb

[LeleFT]

Non necessariamente.
L'unico vincolo è che il nuovo metodo NON PUO' dichiarare di rilanciare eccezioni checked DIVERSE (gerarchicamente) da quelle dichiarate dal metodo originario o più ampie. Può, invece, dichiarare di lanciare eccezioni più specifiche (sottoclassi di quelle dichiarate dal metodo originario), essere più restrittivo e non dichiararne alcuna oppure dichiarare di rilanciare eccezioni unchecked.


Ciao.

[blubossa]

...vediamo se ho capito...............
quindi se nel metodo originario dichiaro unchecked il metodo di override non può dichiarare checked. Giusto?
nel metodo di override posso non dichiarare nessuna eccezione oppure ne posso dichirare una più restrittiva. Corretto?

Scusami se ho ripreso il concetto ma voglio essere sicuro di aver capito bene.

ho appena fatto una prova a dichiare e non dichiarare l'eccezione...funziona perfettamente!!!

grazie
bb

[blubossa]

...noooo se lo riscrivo il throws mi va in errore!!! ho fatto una c...ta??

[LeleFT]

Checked o unchecked sono tipi di eccezione, non tipi di metodo. Le eccezioni "checked" sono quelle che il programmatore è obbligato a catturare con un try/catch o a delegare con un throws. Le eccezioni "unchecked" sono quelle che il programmatore non è obbligato a catturare o delegare (ovvero, tutte le RuntimeException e derivate).

Vedo di rispiegare, magari con qualche esempio, la faccenda dell'override.

Denoto con A il metodo originale e con B il metodo che ne fa l'override.

Se A non dichiara alcuna eccezione checked, B non può dichiarare nessuna eccezione checked.

Se A dichiara di rilanciare un'eccezione X, B può:

1) Non dichiarare nulla
2) Dichiarare di rilanciare eccezioni di tipo X
3) Dichiarare di rilanciare eccezioni di tipo Y derivante da X (quindi Y extends X, ovvero più specifiche)
4) Dichiarare di rilanciare eccezioni di tipo Y unchecked (quindi Y extends RuntimeException)

B non può:

1) Dichiarare di rilanciare eccezioni di tipo Y che non derivino da X
2) Dichiarare di rilanciare eccezioni di tipo Y che siano più ampie di X (ovvero, che siano superclasse di X, cioè X extends Y)

Esempio.

public class Base {
   public void metodo() throws IOException { ... }
}

public class Derivata extends Base {
   // 1
   @Override
   public void metodo() { ... }                                // Legale

   // 2
   @Override
   public void metodo() throws IOxception { ... }              // Legale

   // 3
   @Override
   public void metodo() throws FileNotFoundException { ... }   // Legale

   // 4
   @Override
   public void metodo() throws NullPointerException { ... }    // Legale

   // 5
   @Override
   public void metodo() throws InterruptedException { ... }    // ILLEGALE

   // 6
   @Override
   public void metodo() throws Exception { ... }               // ILLEGALE
}

1) E' legale perchè il nuovo metodo può non dichiarare nulla
2) E' legale perchè dichiara di rilanciare lo stesso identico tipo di eccezione
3) E' legale perchè dichiara di rilanciare un'eccezione che è più specifica (che deriva da IOException)
4) E' legale perchè NullPointerException è di tipo unchecked (deriva da RuntimeException)
5) E' illegale perchè dichiara di rilanciare un'eccezione diversa (non figlia) da quelle dichiarate dal metodo originario
6) E' illegale perchè dichiara di rilanciare un'eccezione più ampia di quella dichiarata dal metodo originario.


Ciao.

[blubossa]

...quindi se il metodo A dichiara come eccezione una checked il metodo B di override può dichiarare un' eccezione uncheckd.
ma i ogni caso il metodo B eredita anche l'eccezione dichiarata in A?

bb

[valia]

Dipende da come dichiari e istanzi gli oggetti.
Guarda qui:

import java.io.IOException;


public class Esempio {
    public void metodo() throws IOException {
    }


}


class Derivata extends Esempio {
    // 1
    @Override
    public void metodo() throws IllegalArgumentException {
    } // Legale


    public static void main() {
        Derivata der = new Derivata();
        der.metodo();
        try {
            Esempio es = new Derivata();
            es.metodo();
        } catch (IOException ex) {


        }
    }
}

dichiari nella classe base (Esempio) il metodo "metodo" che lancia una eccezione checked (IOException).
La classe figlia (Derivata), toglie l'eccezione checked e ne mette una unchecked.

Poi ho fatto un piccolo main:
nel primo caso (dichiaro un oggetto di tipo Derivata e lo istanzio come Derivata), non ho nessun problema, l'eccezione checked non c'è e dell'altra non sono obbligata a farne un check.
Nel secondo caso, dichiaro un oggetto di tipo Esempio ma lo istanzio come Derivata. Come noti, ho dovuto gestire l'eccezione, perché in fase di compilazione, per metodo vale la signature del padre, che prevede l'eccezione checked

Direi quindi che se dichiari e usi la classe derivata, la figlia non eredita l'eccezione, se dichiari la classe padre, ma istanzi la figlia, purtroppo l'eccezione "la erediti" e devi trattarla

[LeleFT]

...quindi se il metodo A dichiara come eccezione una checked il metodo B di override può dichiarare un' eccezione uncheckd.
ma i ogni caso il metodo B eredita anche l'eccezione dichiarata in A?

bb

Il rilancio delle eccezioni NON VIENE ereditato.
Se il nuovo metodo dichiara MENO eccezioni (checked) di quelle del metodo originario, allora significa che quel metodo fa un lavoro diverso, ed eventuali eccezioni se le gestisce lui. Poi dipende dal tipo statico su cui viene invocato il metodo. Se il metodo lo invochi su un riferimento di tipo "ClasseBase", il compilatore non ha modo di sapere se l'oggetto realmente istanziato è di tipo "ClasseBase" o di una sua derivata più specifica... quindi, deve accontentarsi di ciò che conosce: e sa che il metodo della classe base può sollevare quelle eccezioni (poco importa se il tipo effettivo non ne solleva affatto perchè se le gestisce lui o perchè fa dell'altro... anzi, meglio, un problema in meno) e che qualunque sua derivata non può sollevarne di diverse.

Un possibile override del metodo può essere questo:

@Override
public void metodo() {   // Nessuna eccezione
   try {
      super.metodo();
   } catch (IOException ioe) {
      ...
   }
}

Il metodo semplicemente richiama quello della superclasse e si occupa integralmente della gestione dell'eccezione. Cosa cambia a livello di uso di questo metodo? Dipende dal modo in cui si tratta l'oggetto:

// So già staticamente che si tratta di un oggetto di classe "Derivata":
// il compilatore sa che il metodo non solleva alcuna eccezione
Derivata d = new Derivata();
d.metodo();

// Non so a priori di che tipo è l'oggetto: il compilatore nemmeno.
// Il compilatore non può sapere se a run-time avrò un oggetto di tipo
// "Derivata" o di tipo "Base" o di altro tipo ancora... quindi, può solo basarsi
// sul tipo statico... che è "Base": e mi obbliga a catturare un eccezione IOException

Base b = recuperaOggetto();   // Questo metodo può tornare un oggetto di tipo "Derivata" oppure di tipo "Base" o di altro tipo, che estenda "Base"
try {
   b.metodo();
} catch (IOException ioe) {
   ioe.printStackTrace();
}

Forse così è più chiaro.


Ciao.