Visualizzazione dei risultati da 1 a 4 su 4

Discussione: [ Java ] Eccezioni

  1. #1

    [ Java ] Eccezioni

    Buon giorno a tutti, mi ritrovo a studiare le eccezioni di Java ad un giorno dall'esame e dalle slide del prof non è che ci ho capito molto... Qualcuno mi potrebbe fare un esempio di eccezione controllata ed eccezione non controllata, dicendomi le differenze ?
    Valar morghulis... Valar dohaeris...

  2. #2
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284

    Re: [ Java ] Eccezioni

    Originariamente inviato da noidhoon
    Buon giorno a tutti, mi ritrovo a studiare le eccezioni di Java ad un giorno dall'esame e dalle slide del prof non è che ci ho capito molto... Qualcuno mi potrebbe fare un esempio di eccezione controllata ed eccezione non controllata, dicendomi le differenze ?
    Eccezione "checked": vale la regola che in inglese si può dire "handle or declare". O la gestisci (catch) o la dichiari (nel metodo con throws). Insomma ... il programmatore non può ignorarla.
    Scenario: un metodo A invoca un altro metodo B. Se B può lanciare una eccezione checked X allora innanzitutto nella dichiarazione di B ci deve essere scritto throws Qualcosa, dove Qualcosa è X o un supertipo.
    Allora nel metodo A ci sono 2 possibilità: invoca B ma mette un catch che può catturare X. Oppure dichiara a sua volta che A può lanciare fuori X. E a sua volta il chiamante avrà lo stesso obbligo: gestire o dichiarare per far uscire a sua volta la eccezione.

    Le eccezioni "checked" sono Throwable, Exception e tutte le sottoclassi di Exception ad eccezione del sottoramo RuntimeException in giù.

    ----------

    Eccezione "unchecked": non si è obbligati né a gestirle né a dichiararle. Si possono fare queste due cose ma il compilatore non obbliga il programmatore a prendere il considerazione una eccezione unchecked.

    Sono tutte quelle da RuntimeException in giù (sottoclassi) e anche Error e sottoclassi (sebbene Error è per errori "gravi" ma è comunque tecnicamente unchecked).
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

  3. #3
    Quindi se ho ben capito, se il prof mi chiede che un metodo in un determinato stato deve lanciare l'eccezione non controllata x, nella classe chiamante posso non gestire l'eccezione. Viceversa, se mi chiede che un metodo in un determinato stato deve lanciare l'eccezione y controllata, io nella classe chiamante devo o gestire l'eccezione o lanciarla di nuovo. Ho capito bene ?

    Se è così non capisco come le distinguo ? Nel senso come faccio a farla gestire o no ?
    Valar morghulis... Valar dohaeris...

  4. #4
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284
    Originariamente inviato da noidhoon
    Quindi se ho ben capito, se il prof mi chiede che un metodo in un determinato stato deve lanciare l'eccezione non controllata x, nella classe chiamante posso non gestire l'eccezione. Viceversa, se mi chiede che un metodo in un determinato stato deve lanciare l'eccezione y controllata, io nella classe chiamante devo o gestire l'eccezione o lanciarla di nuovo. Ho capito bene ?
    Sì, il concetto è questo. Quando dici "o lanciarla di nuovo" .... sì, certo, potresti anche catturarla e rilanciarla tu. Ma se non la gestisci e ti limiti solo a dichiararla .... esce già da sola! (cioè non devi lanciarla espressamente tu).

    Originariamente inviato da noidhoon
    Se è così non capisco come le distinguo ? Nel senso come faccio a farla gestire o no ?
    A dire il vero non ho capito io il tuo dubbio. Non è che devi tanto "distinguere" tu con del codice (anche .. si può fare). Ma il criterio è un altro: se tu invochi un metodo che "sai" che lancia una eccezione checked, allora sai già che devi scrivere il codice per o gestirla o farla passare oltre.

    In una certa classe Xyz hai es:

    public static void copiaFile(String sorg, String dest) throws IOException { ..... }

    IOException è "checked" (estende Exception).

    Da un'altra parte devi scrivere un metodo() che usa copiaFile() e hai 2 opzioni per scriverlo:

    codice:
    public void metodo() {
        try {
            Xyz.copiaFile("pippo.txt", "pluto.txt");
        } catch (IOException e) {
            System.err.println(e);
        }
    }
    oppure
    codice:
    public void metodo() throws IOException {
        Xyz.copiaFile("pippo.txt", "pluto.txt");
    }
    Nel primo caso l'hai gestita, nel secondo caso no e il metodo() si limita solo a dichiararla. Vuol dire che metodo() non fa nulla riguardo la eccezione e IOException può uscire fuori da metodo(). Ed essendo checked, chi invocherà metodo() dovrà poi porsi la stessa questione.

    Ci sono anche soluzioni un po' "ibride", cioè catturi e rilanci la stessa eccezione o magari un'altra eventualmente con il significato più appropriato per il tuo livello di astrazione.

    codice:
    public void metodo() throws IOException {
        try {
            Xyz.copiaFile("pippo.txt", "pluto.txt");
        } catch (IOException e) {
            System.err.println(e);
            throw e;   // Rilancio!!
        }
    }
    Qui catturo IOException, stampo la eccezione (es. per questioni di debug/log) e la rilancio pari pari. Ovviamente metodo() deve dichiararla!

    codice:
    public void metodo() throws MiaException {
        try {
            Xyz.copiaFile("pippo.txt", "pluto.txt");
        } catch (IOException e) {
            throw new MiaException("Copia file fallita", e);
        }
    }
    Qui catturo IOException ma poi lancio un'altra eccezione (supponiamo checked anch'essa) che ha un messaggio specifico e "incapsula" la eccezione.
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.