Delucidazione su eccezioni

di il
4 risposte

Delucidazione su eccezioni

Ciao a tutti,

nonostante abbia bene capito la teoria dell'eccezioni non ho ben capito nella pratica quando bisogna usarle.
Mi spiego meglio: vorrei sapere quelle piccole "Regole di buona programmazione" che spesso non sono scritte sui libri, quelle operazioni che volendo è possibile fare ma è meglio se si fanno in un modo alternativo. (Scusate la domanda...mi rendo conto che è fin troppo generale e si potrebbe scrivere moltissimo)

Esempio -> è un buona cosa delegare un eccezzione, intercettata da un catch, al metodo chiamante per gestirla in un try-catch piu grande?

Non mi occorono spiegazioni troppo basilari in quanto, avendo una conoscenza/esperienza di programmazione prettamente scolastica, ne ho gia lette assai (anche se non sono mai troppe)

Inoltre conoscete qualche sito che dato una certa parola chiave, rappresentante una operazione o argomento, mostra l'elenco di tutte le eccezione che ne hanno a che fare?
(esempio data la parola "file" si potrebbe ricevere un elenco in cui è presente la classe FileNotFoundException, insieme magari ad altre classsi del quale ora mi sfugge il nome....tipo quella generata se la lettura si interrompe)

Grazie

4 Risposte

  • Re: Delucidazione su eccezioni

    glcbattocchio ha scritto:


    Esempio -> è un buona cosa delegare un eccezzione, intercettata da un catch, al metodo chiamante per gestirla in un try-catch piu grande?
    Partiamo da un aspetto importante che bisogna sempre tenere in considerazione: detto in generale, ha senso gestire (cioè fare catch ( ..... ) { .... } con dentro qualcosa di "utile") solo ad un livello in cui SAI come poter "reagire" in modo appropriato, ad esempio mostrando un messaggio all'utente oppure facendo terminare/fallire qualcos'altro o restituendo un default da un metodo o altre cose del genere.

    Facciamo un esempio molto banale, un metodo es.

    public static void copiaFile(File sorgente, File destinazione) throws IOException

    contenuto in una classe es. FileUtilities, ha senso fare un catch lì dentro? In generale: NO. O perlomeno, l'unica cosa per cui può aver senso fare un catch lì dentro è per fare del "logging" (della eccezione, chiaramente). Ma dovrebbe comunque poi ributtare fuori la eccezione. Ecco perché c'è il throws IOException.
    Il punto è che questo copiaFile "non sa" dove viene usato, è molto a "basso" livello. Potrebbe essere usato in una applicazione Java "console", o in una applicazione grafica con JavaFX o in un web service, ecc...
    Se il copiaFile lo invoco da un actionPerformed() di un listener in una GUI Swing, allora so (nel actionPerformed) che sono nel contesto di una interfaccia grafica e che (presumibilmente) la copia è stata richiesta dall'utente con una certa azione. Allora nel actionPerformed posso fare il catch di IOException e mostrare una messagebox all'utente "la copia del file è fallita".

    glcbattocchio ha scritto:


    Inoltre conoscete qualche sito che dato una certa parola chiave, rappresentante una operazione o argomento, mostra l'elenco di tutte le eccezione che ne hanno a che fare?
    (esempio data la parola "file" si potrebbe ricevere un elenco in cui è presente la classe FileNotFoundException, insieme magari ad altre classsi del quale ora mi sfugge il nome....tipo quella generata se la lettura si interrompe)
    La documentazione "javadoc" del framework standard (e di tantissime altre librerie/framework Java) fornisce già un elenco di tutte le classi. Oltre ovviamente a descrivere classi, metodi ecc... con tipicamente anche le eccezioni lanciate da ciascun metodo.

    Poi se vuoi fare ricerche davvero estese, ci sono siti come grepcode.com dove se cerchi es. File te lo cerca in una quantità spropositata di librerie e framework.

    Ma quello che è più importante è saper leggere e capire la documentazione "javadoc".
  • Re: Delucidazione su eccezioni

    Ciao andbin,

    Inanzi tutto grazie per la risposta.
    La prima parte della risposta mi è molto utile, me la ricordero sicuramente metre scriverò del codice. Era una cosa a cui non avevo mai pensato, anche perche non l'avevo mai letta sui libri su cui studiavo, però in effetti è logica.

    Invece per quanto riguarda la parte dove commenti l'esempio del metodo copiaFIle l'ho capita un po meno, piu precisamente ho capito poco la parte in cui nominavi certe classi, che penso, vengano utilizzati per la grafica.
    Penso comunque di aver capito bene il concetto generale che volevi dirmi: a volte è meglio delegare l'eccezzioni al posto di gestirle immediatamente. Questo anche per rendere più generali i metodi. Giusto?

    grepcode.com non lo conoscevo, ora lo guardo un po. Javadoc lo conosco e lo sto usando tantissimo. (Ho iniziato a fare java in modo serio quest'anno, faccio informatica all'università)

    Infine volevo fare un'altra domanda: solitamente come ci si comporta per la gestione dell'eccezioni nei catch? Solitamente io mando in output il messaggio di errore ma pensando a operazioni piu grandi non penso che basti.
  • Re: Delucidazione su eccezioni

    glcbattocchio ha scritto:


    Invece per quanto riguarda la parte dove commenti l'esempio del metodo copiaFIle l'ho capita un po meno, piu precisamente ho capito poco la parte in cui nominavi certe classi, che penso, vengano utilizzati per la grafica.
    Sì .. ok. Non importa molto in questo contesto se non sai cosa è JavaFX o un actionPerformed() di Swing.

    Il punto è la questione in generale: determinare in quale/i punto/i del codice hai nozione più chiara di come reagire di fronte ad una eccezione.
    Detto in generale: più la funzionalità di un metodo è a "basso" livello, meno c'è capacità di gestire appropriatamente una eccezione (salvo il caso del logging).

    glcbattocchio ha scritto:


    Infine volevo fare un'altra domanda: solitamente come ci si comporta per la gestione dell'eccezioni nei catch? Solitamente io mando in output il messaggio di errore ma pensando a operazioni piu grandi non penso che basti.
    Dipende appunto dal contesto in cui sei e da quale è la ragione per cui salta fuori una eccezione.

    Se è l'utente che ha richiesto l'apertura di un file (specificando un nome) e una classe di I/O ti lancia FileNotFoundException, allora ha certamente senso dire all'utente che il file non l'ha trovato e DARE (possibilmente) all'utente la possibilità di richiedere un altro file.

    Se l'applicazione ha bisogno di un file "interno" (es. di configurazione) all'applicazione e ti sbuca fuori FileNotFoundException, puoi certamente far fallire qualcosa (o addirittura l'intera applicazione, facendola terminare) e magari dicendo qualcosa di più o meno specifico all'utente. Ma è comunque o un "baco" o un problema di impostazione e va pertanto indagato e risolto. L'utente in questo caso non potrebbe fare/ripetere nulla.
  • Re: Delucidazione su eccezioni

    Grazie dei suggerimenti...scusa il ritardo
Devi accedere o registrarti per scrivere nel forum
4 risposte