Quando scegliere eccezioni checked e unchecked

StackOverflow https://stackoverflow.com/questions/27578

Domanda

In Java (o qualsiasi altra lingua selezionata eccezioni), quando si crea una propria classe di eccezione, come si fa a decidere se deve essere selezionata o deselezionata?

Il mio istinto è quello di dire che una eccezione controllata vorresti essere chiamato per i casi in cui il chiamante potrebbe essere in grado di recuperare in qualche modo produttivo, dove, come un incontrollato eccezione sarebbe più irrecuperabili casi, ma sarei interessato ad altri pensieri.

È stato utile?

Soluzione

Controllato Eccezioni sono grandi, così a lungo come si capisce quando deve essere utilizzato.Java API di base non riesce a seguire queste regole per SQLException (e a volte per IOException), che è il motivo per cui sono così terribili.

Controllato Eccezioni dovrebbe essere utilizzato per prevedibile, ma inevitabile errori che sono ragionevole per recuperare da.

Eccezioni Unchecked dovrebbe essere usato per tutto il resto.

Io scomposizione per voi, perché la maggior parte delle persone fraintendono ciò che questo significa.

  1. Prevedibile, ma inevitabile:Il chiamante ha fatto tutto quanto in loro potere per convalidare i parametri di input, ma qualche condizione al di fuori del loro controllo ha causato il fallimento dell'operazione.Per esempio, si tenta la lettura di un file, ma qualcuno lo elimina dal momento in cui è verificare se esiste e il tempo l'operazione di lettura inizia.Dichiarando una eccezione controllata, si indica al chiamante di anticipare questo fallimento.
  2. Ragionevole per recuperare da:Non c'è nessun punto a raccontare ai chiamanti di anticipare le eccezioni che non possono recuperare.Se un utente tenta di leggere da un file non esistente, il chiamante può richiedere loro un nuovo nome di file.D'altra parte, se il metodo ha esito negativo a causa di un bug (non valido per gli argomenti di metodo o un buggy implementazione del metodo) non c'è nulla che l'applicazione può fare per risolvere il problema a metà esecuzione.La cosa migliore che possa fare è registrare il problema e aspettare che lo sviluppatore per risolvere in un secondo momento.

A meno che l'eccezione si stanno gettando incontra tutti delle condizioni di cui sopra si dovrebbe utilizzare una Eccezione Unchecked.

Rivalutare ad ogni livello:A volte il metodo cattura l'eccezione controllata non è il posto giusto per gestire l'errore.In questo caso, prendere in considerazione ciò che è ragionevole per il vostro chiamanti.Se l'eccezione è prevedibile, inevitabile e ragionevole per recuperare da allora si dovrebbe lanciare una eccezione controllata di te.Se non, si dovrebbe avvolgere l'eccezione in una eccezione unchecked.Se si segue questa regola, vi troverete di conversione controllato eccezioni unchecked eccezioni e viceversa a seconda che livello siete.

Per entrambi i checked e unchecked eccezioni, utilizzare il giusto livello di astrazione.Per esempio, un repository di codice con due diverse implementazioni di database e file system) dovrebbe evitare di esporre l'attuazione dettagli specifici da buttare SQLException o IOException.Invece, si dovrebbe avvolgere l'eccezione in un'astrazione che si estende a tutte le implementazioni (ad es. RepositoryException).

Altri suggerimenti

Da Java Studente:

Quando si verifica un'eccezione, è necessario interferire e gestire l'eccezione, o dire al compilatore che non si può gestire si dichiarando che il tuo metodo lancia l'eccezione, quindi il codice che utilizza il metodo dovrà gestire l'eccezione (anche se anche può scegliere di dichiarare che essa genera l'eccezione se non riesce a gestirlo).

Compilatore verifica che abbiamo fatto una delle due cose (la cattura, o dichiarare).Quindi, questi sono chiamati Controllato le eccezioni.Ma gli Errori, e di Runtime Le eccezioni non vengono controllati da compilatore (anche se si può scegliere per la cattura, o di dichiarare, non è richiesto).Così, questi due sono chiamati Eccezioni Unchecked.

Errori vengono utilizzati per rappresentare le condizioni che si verificano al di fuori del l'applicazione, come ad esempio crash del sistema.Le eccezioni Runtime sono di solito si verificano per colpa del la logica dell'applicazione.Non si può fare nulla in queste situazioni.Quando eccezione di runtime si verificano, è necessario ri-scrivere il codice del programma.Così, in questi non sono controllati dal compilatore.Questi le eccezioni runtime sarà scoprire in di sviluppo, e periodo di prova.Quindi abbiamo il refactoring del codice rimuovere questi errori.

La regola che uso io è:non utilizzare mai spuntata eccezioni!(o quando non si vede alcun modo intorno ad esso)

C'è un forte caso per il contrario:Non utilizzare mai controllato eccezioni.Sono riluttante a prendere posizione nel dibattito, ma sembra che ci sia un ampio consenso sul fatto che l'introduzione di eccezioni selezionate è stata una decisione sbagliata col senno di poi.Si prega di non sparare al messaggero e si riferiscono a quelli argomenti.

Su qualsiasi abbastanza grande sistema, con molti strati, eccezione controllata sono inutili in quanto, comunque, è necessario un livello architettonico strategia per gestire come verrà gestito l'eccezione (l'uso di un errore di barriera)

Con eccezioni selezionate di gestione degli errori di strategia è la micro-gestito e il suo insopportabile su qualsiasi sistema di grandi dimensioni.

La maggior parte del tempo, non sai se un errore è "recuperabile", perché non si sa a quale livello il chiamante dell'API si trova.

Diciamo che ho creato un StringToInt API che converte la rappresentazione di stringa di un numero intero Int.Devo lanciare una eccezione controllata se l'API è chiamato con il "pippo" stringa ?È recuperabile ?Non so perché nel suo strato chiamante del mio StringToInt API può già avere convalidato l'ingresso, e se questa viene generata un'eccezione, è un bug o una corruzione dei dati e non è recuperabile per questo livello.

In questo caso il chiamante di API non vuole prendere l'eccezione.Lui vuole solo lasciare che l'eccezione "bolle".Se ho scelto una eccezione controllata, questo chiamante avrà un sacco di inutili blocco catch solo artificialmente rigenerare l'eccezione.

Che cosa è recuperabile dipende la maggior parte del tempo sul chiamante dell'API, non il writter delle API.Un'API non dovrebbero usare controllato eccezioni sono solo eccezioni unchecked permette di scegliere o di cattura o di ignorare un'eccezione.

Sei corretto.

Eccezioni Unchecked sono utilizzati per consentire al sistema di fail fast che è una buona cosa.Si dovrebbe indicare chiaramente qual è il tuo metodo di attesa per poter funzionare correttamente.In questo modo è possibile convalidare l'input solo una volta.

Per esempio:

/**
 * @params operation - The operation to execute.
 * @throws IllegalArgumentException if the operation is "exit"
 */
 public final void execute( String operation ) {
     if( "exit".equals(operation)){
          throw new IllegalArgumentException("I told you not to...");
     }
     this.operation = operation; 
     .....  
 }
 private void secretCode(){
      // we perform the operation.
      // at this point the opreation was validated already.
      // so we don't worry that operation is "exit"
      .....  
 }

Solo per mettere un esempio.Il punto è che se il sistema non è veloce, poi saprete dove e perché ha fatto fallire.Si otterrà un stacktrace come:

 IllegalArgumentException: I told you not to use "exit" 
 at some.package.AClass.execute(Aclass.java:5)
 at otherPackage.Otherlass.delegateTheWork(OtherClass.java:4569)
 ar ......

E sai cosa è successo.Il OtherClass in "delegateTheWork" metodo ( in linea 4569 ) chiamato la classe con il "uscire" valore, anche quando non dovrebbe, etc.

Altrimenti si dovrebbe cospargere le convalide di tutto il codice e soggetto a errori.Inoltre, a volte è difficile tenere traccia di ciò che è andato storto e si può aspettare ore di frustrante debug

Stessa cosa succede con NullPointerExceptions.Se si dispone di un 700 linee di classe del 15 metodi, che utilizza il 30 attributi e nessuno di essi può essere null, invece di convalida in ciascuno di questi metodi per il supporto di valori null si potrebbe fare tutti gli attributi di sola lettura e della convalida da parte del costruttore o del metodo factory.

 public static MyClass createInstane( Object data1, Object data2 /* etc */ ){ 
      if( data1 == null ){ throw NullPointerException( "data1 cannot be null"); }

  }


  // the rest of the methods don't validate data1 anymore.
  public void method1(){ // don't worry, nothing is null 
      ....
  }
  public void method2(){ // don't worry, nothing is null 
      ....
  }
  public void method3(){ // don't worry, nothing is null 
      ....
  }

Controllato eccezioni Sono utili per quando il programmatore ( tu o i tuoi collaboratori ) ha fatto tutto giusto, convalidato l'ingresso, eseguito test, e tutto il codice è perfetto, ma il codice si collega a terzi webservice che può essere verso il basso ( o un file si utilizza è stato eliminato da un altro processo esterno, ecc ) .Il webservice può anche essere convalidare prima il tentativo di connessione, ma durante il trasferimento dei dati qualcosa è andato storto.

In questo scenario non c'è nulla che tu o i tuoi collaboratori possono fare per aiutare.Ma ancora si deve fare qualcosa e non lasciare che l'applicazione solo morire e scomparire agli occhi dell'utente.Si utilizza una eccezione controllata e gestire l'eccezione, cosa si può fare quando succede?, la maggior parte del tempo , solo per tentare di registrare l'errore, probabilmente salvare il tuo lavoro ( l'app funziona ) e presentare un messaggio per l'utente.( Il sito blabla è basso, si prega di riprovare più tardi etc.)

Se l'eccezione controllata sono troppo ( con l'aggiunta del "buttare " Eccezione" in tutti i metodi di firme ) , quindi il codice diventa molto fragile, perché ognuno si ignora che l'eccezione ( perché è troppo generico ) e la qualità del codice sarà seriamente compromessa.

Se si abusa unchecked exception qualcosa di simile accadrà.Gli utenti di quel codice non so se qualcosa può andare storto un po ' di try{...}catch( Throwable t ) apparirà.

Ecco il mio finale "regola del pollice".
Io uso:

  • unchecked exception all'interno del codice del mio metodo per un l'errore dovuto al chiamante (che comporta un esplicita e completa documentazione)
  • eccezione controllata per un fallimento a causa della chiamato che ho bisogno di fare esplicito per chi vuole utilizzare il mio codice

Confrontare la risposta precedente, questa è una chiara motivazione (su cui si può essere d'accordo o in disaccordo) per l'uso di uno o l'altro (o entrambi) tipo di eccezioni.

Per entrambe le eccezioni, voglio creare il mio bagaglio controllato Eccezione per la mia applicazione (una buona pratica, come indicato qui), fatta eccezione per molto comune unchecked exception (come NullPointerException)

Così, per esempio, l'obiettivo di questa particolare funzione sotto è per fare (o farsi se esiste già) un oggetto,
significato:

  • il contenitore di un oggetto per fare/ottenere DEVE esistere (responsabilità del CHIAMANTE
    => unchecked exception, E chiaro commento javadoc per questo chiamata di funzione)
  • gli altri parametri non può essere null
    (a scelta del programmatore di metterlo sul CHIAMANTE:il coder non si verifica per parametro null, ma il coder NON DOCUMENTO)
  • il risultato NON PUÒ ESSERE NULL
    (responsabilità e la scelta del codice del chiamato, scelta che sarà di grande interesse per il chiamante
    => controllato eccezione, perché tutti i chiamanti DEVONO prendere una decisione se l'oggetto non può essere creato trovato, e che la decisione deve essere eseguita a tempo di compilazione:essi non possono utilizzare questa funzione senza avere a che fare con questa possibilità, cioè, con questo controllato eccezione).

Esempio:

/**
 * Build a folder. <br />
 * Folder located under a Parent Folder (either RootFolder or an existing Folder)
 * @param aFolderName name of folder
 * @param aPVob project vob containing folder (MUST NOT BE NULL)
 * @param aParent parent folder containing folder 
 *        (MUST NOT BE NULL, MUST BE IN THE SAME PVOB than aPvob)
 * @param aComment comment for folder (MUST NOT BE NULL)
 * @return a new folder or an existing one
 * @throws CCException if any problems occurs during folder creation
 * @throws AssertionFailedException if aParent is not in the same PVob
 * @throws NullPointerException if aPVob or aParent or aComment is null
 */
static public Folder makeOrGetFolder(final String aFoldername, final Folder aParent,
    final IPVob aPVob, final Comment aComment) throws CCException {
    Folder aFolderRes = null;
    if (aPVob.equals(aParent.getPVob() == false) { 
       // UNCHECKED EXCEPTION because the caller failed to live up
       // to the documented entry criteria for this function
       Assert.isLegal(false, "parent Folder must be in the same PVob than " + aPVob); }

    final String ctcmd = "mkfolder " + aComment.getCommentOption() + 
        " -in " + getPNameFromRepoObject(aParent) + " " + aPVob.getFullName(aFolderName);

    final Status st = getCleartool().executeCmd(ctcmd);

    if (st.status || StringUtils.strictContains(st.message,"already exists.")) {
        aFolderRes = Folder.getFolder(aFolderName, aPVob);
    }
    else {
        // CHECKED EXCEPTION because the callee failed to respect his contract
        throw new CCException.Error("Unable to make/get folder '" + aFolderName + "'");
    }
    return aFolderRes;
}

Non è solo una questione di capacità di ripristinare l'eccezione.Ciò che conta di più, a mio parere, è se il chiamante è interessato a catturare l'eccezione o non.

Se si scrive una libreria per essere utilizzato altrove, o un basso livello di applicazione, chiedetevi se il chiamante è interessato a prendere (conoscere) l'eccezione.Se egli non è, quindi utilizzare una eccezione unchecked, quindi non c'onere lui inutilmente.

Questa è la filosofia adottata da molti quadri.Spring e hibernate, in particolare, vengono in mente - conversione conosciuto controllato eccezione unchecked exception proprio perché controllato eccezioni sono troppo in Java.Un esempio che mi viene in mente è la JSONException da json.org che è una eccezione controllata ed è per lo più fastidioso, dovrebbe essere deselezionata, ma lo sviluppatore, semplicemente, non hanno pensato.

A proposito, la maggior parte del tempo il chiamante l'interesse e l'eccezione è direttamente correlata alla capacità di ripristinare l'eccezione, ma che non è sempre il caso.

Qui è una soluzione molto semplice per il tuo Selezionata/Deselezionata dilemma.

Regola 1:Pensare a una Incontrollata Eccezione come verificabile condizione prima dell'esecuzione del codice.per esempio...

x.doSomething(); // the code throws a NullPointerException

dove x è null......il codice dovrebbe forse avere i seguenti...

if (x==null)
{
    //do something below to make sure when x.doSomething() is executed, it won’t throw a NullPointerException.
    x = new X();
}
x.doSomething();

Regola 2:Pensare ad una Eccezione Controllata come un non-verificabile condizione che può verificarsi durante l'esecuzione del codice.

Socket s = new Socket(“google.com”, 80);
InputStream in = s.getInputStream();
OutputStream out = s.getOutputStream();

...nell'esempio di cui sopra, l'URL (google.com) potrebbe non essere disponibile a causa dei DNS server verso il basso.Anche a l'istante in cui il server DNS di lavoro e risolto il ‘google.com’ nome in un indirizzo IP, se la connessione viene effettuata a google.com, in qualsiasi momento, postfazione, la rete potrebbe andare verso il basso.Semplicemente non si può testare la rete in tutto il periodo precedente la lettura e la scrittura dei flussi.

Ci sono volte in cui il codice deve semplicemente eseguire prima di poter sapere se c'è un problema.Costringendo gli sviluppatori a scrivere il codice in modo tale da costringerli a gestire queste situazioni via Eccezione Controllata, mi punta il mio cappello per il creatore di Java che ha inventato questo concetto.

In generale, quasi tutte le Api in Java seguire le 2 regole di cui sopra.Se si tenta di scrivere in un file, il disco potrebbe riempire prima di completare la scrittura.È possibile che altri processi che aveva causato il disco a diventare piena.Semplicemente non c'è modo per verificare questa situazione.Per coloro che interagiscono con l'hardware in cui, in qualsiasi momento, utilizzando l'hardware può fallire, Controllato Eccezioni sembrano essere un'elegante soluzione per questo problema.

C'è una zona grigia di questo.Nel caso In cui molti test sono necessari (una mente che soffia istruzione if con un sacco di && e ||), l'eccezione generata sarà un CheckedException semplicemente perché è troppo di un dolore per ottenere il diritto — che non si può dire che questo problema è un errore di programmazione.Se ci sono molto di meno di 10 test (ad es.‘if (x == null)’), poi il programmatore di errore dovrebbe essere un UncheckedException.

Le cose si fanno interessanti quando si tratta con interpreti di lingua.Secondo le regole di cui sopra, in caso di Errore di Sintassi essere considerata una Selezionata o Deselezionata Eccezione?Direi che se la sintassi di un linguaggio può essere testato prima viene eseguito, deve essere un UncheckedException.Se la lingua non può essere testato simile al modo in cui il codice assembly viene eseguito su un personal computer, e poi l'Errore di Sintassi dovrebbe essere una Eccezione Controllata.

Le 2 regole di cui sopra sarà probabilmente rimuovere il 90% della vostra preoccupazione in cui scegliere.Per riassumere le regole, seguire questo schema... 1) se il codice da eseguire possono essere testato prima di eseguire per funzionare correttamente e, se si verifica un'Eccezione — un.k.un.un programmatore di errore, l'Eccezione deve essere un UncheckedException (una sottoclasse di RuntimeException).2) se l'esecuzione di codice non possono essere testati prima è eseguito per funzionare correttamente, l'Eccezione deve essere una Eccezione Controllata (una sottoclasse di Exception).

Si può chiamare una selezionata o deselezionata eccezione;tuttavia, entrambi tipi di eccezione può essere catturato dal programmatore, in modo che la risposta migliore è:scrivere tutti di eccezioni come deselezionata e i documenti.Che modo lo sviluppatore che utilizza le API possono scegliere se lui o lei vuole catturare l'eccezione e fare qualcosa.Controllato le eccezioni sono una completa perdita di tempo di tutti e rende il vostro codice di un orribile incubo a guardare.La corretta unità di test sarà quindi visualizzare tutte le eccezioni che si possono prendere e fare qualcosa.

Eccezione Controllata: Se il client è in grado di recuperare da un'eccezione e vorrei continuare ad utilizzare eccezione controllata.

Unchecked Exception: Se un client non può fare qualsiasi cosa dopo che l'eccezione, e quindi sollevare eccezioni non controllata.

Esempio:Se si sono tenuti a fare operazioni aritmetiche in un metodo A() e si basa su l'output(), ad un'altra operazione.Se l'uscita è null da Un metodo() che non si aspettano durante il tempo di esecuzione, quindi si sono tenuti a gettare Null pointer Exception che è tempo di Esecuzione eccezione.

Riferimento qui

Concordo con la preferenza per deselezionato eccezioni come regola, soprattutto quando si progetta un'API.Il chiamante può sempre scegliere di prendere un documentato e non eccezione.Sei solo non inutilmente di forzare il chiamante.

Trovo controllato eccezioni utile al livello inferiore, come l'attuazione di dettaglio.Spesso mi sembra un migliore flusso di un meccanismo di controllo di dover gestire un determinato errore "codice di ritorno".A volte può aiutare a vedere l'impatto di un'idea per un basso livello di modifica del codice di troppo...dichiarare una eccezione controllata downstream e vedere chi avrebbe bisogno di regolare.Quest'ultimo punto non si applica se ci sono un sacco di generico: catch(Exception e) o throws Exception che di solito non è troppo ben pensato comunque.

Qui voglio condividere la mia opinione ho dopo molti anni di esperienza di sviluppo:

  1. Eccezione controllata.Questa è una parte del business di caso d'uso o il flusso di chiamate, questa è una parte della logica dell'applicazione ci aspettiamo o non previsto.Per esempio la connessione rifiutata, condizione non è soddisfatta, etc.Abbiamo bisogno di gestire e visualizzare il messaggio di errore corrispondente all'utente con istruzioni su cosa è successo e cosa fare (di riprovare più tardi ecc).Io di solito la chiamo post-elaborazione eccezione o "utente" di eccezione.

  2. Unchecked exception.Questa è una parte della programmazione eccezione, qualche errore nel codice del software di programmazione (bug, difetti) e riflette il modo in cui i programmatori devono utilizzare delle API per la documentazione.Se un esterno lib/quadro doc dice che si aspetta di ottenere i dati in un certo intervallo e non nulla, perché NPE o IllegalArgumentException sarà gettato, il programmatore deve aspettare e utilizzare API correttamente come da documentazione.Altrimenti l'eccezione viene generata.Io di solito la chiamo pre-trattamento di eccezione o di "validazione" di eccezione.

Dal target di riferimento.Ora parliamo di target o di un gruppo di persone che le eccezioni sono state progettate (a mio parere):

  1. Eccezione controllata.Target di riferimento sono gli utenti/clienti.
  2. Unchecked exception.Target di riferimento sono gli sviluppatori.In altri termini unchecked exception sono progettati solo per gli sviluppatori.

Con lo sviluppo di applicazioni fase del ciclo di vita.

  1. Eccezione controllata è progettato per esistere durante tutto il ciclo di vita di produzione come normale e previsto un meccanismo di un'applicazione gestisce casi eccezionali.
  2. Unchecked exception è concepito per essere solo durante lo sviluppo di applicazioni di collaudo/ciclo di vita, tutti dovrebbero essere risolti durante quel tempo, e non dovrebbe essere lanciata quando un'applicazione è in esecuzione in produzione già.

Il motivo per cui i quadri di solito uso incontrollato eccezioni (la Primavera, per esempio) è che il framework non è possibile determinare la logica di business dell'applicazione, questo è compito degli sviluppatori per la cattura di allora e di progettazione logica.

Controllato eccezioni sono utili per eventuali casi in cui si voglia fornire informazioni al chiamante (cioèautorizzazioni insufficienti, file non trovato, ecc).

Eccezioni Unchecked sono usati raramente, se non a tutti, per informare l'utente o il programmatore di gravi errori o imprevisti condizioni durante la fase di esecuzione.Non buttarli, se si sta scrivendo codice o librerie che saranno utilizzati da parte di altri, in quanto potrebbero non essere in attesa del tuo software per lanciare eccezioni unchecked poiché il compilatore non ha la forza di essere catturati o dichiarato.

Whnever un'eccezione è meno probabile previsto, e si può procedere anche dopo che la cattura, e non possiamo fare nulla per evitare che eccezione, siamo in grado di utilizzare eccezione controllata.

Ogni volta che abbiamo voglia di fare qualcosa di significativo quando un particolare eccezioni succede e quando l'eccezione è previsto, ma non certo, quindi è possibile utilizzare eccezione controllata.

Ogni volta che eccezione la navigazione nei vari livelli, non abbiamo bisogno di prenderlo in ogni livello, in questo caso, possiamo utilizzare eccezione di runtime o avvolgere eccezione unchecked exception.

Eccezione di Runtime viene utilizzato quando l'eccezione più probabile che sia successo, non c'è modo di andare avanti e nulla può essere recuperabile.Quindi in questo caso siamo in grado di prendere precauzioni con riferimento a tale eccezione.EX:NUllPointerException, ArrayOutofBoundsException.Questi sono più probabile che accada.In questo scenario, siamo in grado di prendere precauzioni durante la codifica per evitare tale eccezione.Altrimenti dovremo scrivere try catch blocchi in ogni dove.

Più in generale possono essere fatte eccezioni Unchecked, meno generale, sono controllati.

Penso che possiamo pensare exeptions da alcune domande:

perché non fa eccezione accadere?Cosa possiamo fare quando succede

per errore, un bug. come un metodo di un oggetto null viene chiamato. 

String name = null;
... // some logics
System.out.print(name.length()); // name is still null here

Questo tipo di eccezione dovrebbe essere risolto in fase di test.In caso contrario, si rompe la produzione, e hai una molto alta bug che deve essere risolto immediatamente.Questo tipo di eccezioni non hanno bisogno di essere controllati.

da input esterni, non è possibile controllare o di fiducia l'uscita di servizio esterno.

String name = ExternalService.getName(); // return null
System.out.print(name.length());    // name is null here

Qui, è necessario verificare se il nome è null se si vuole continuare quando è nullo, in caso contrario, è possibile farlo da solo e non si è fermata qui e dare il chiamante l'eccezione di runtime.Questo tipo di eccezioni non hanno bisogno di essere controllati.

da eccezione di runtime da esterno, non è possibile controllare o di fiducia servizio esterno.

Qui, è necessario prendere tutte le eccezioni da ExternalService se si desidera continuare, quando succede, in caso contrario, è possibile farlo da solo e non si è fermata qui e dare il chiamante l'eccezione di runtime.

da eccezione controllata da esterno, non è possibile controllare o di fiducia servizio esterno.

Qui, è necessario prendere tutte le eccezioni da ExternalService se si desidera continuare, quando succede, in caso contrario, è possibile farlo da solo e non si è fermata qui e dare il chiamante l'eccezione di runtime.

In questo caso, abbiamo bisogno di sapere che tipo di eccezione di successo in ExternalService? Dipende:

  1. se è possibile gestire alcuni tipi di eccezioni, avete bisogno di catturarli e di processo.Per gli altri, la bolla di loro.

  2. se avete bisogno di accedere o di risposta a un utente specifico execption, si può prendere.Per gli altri, la bolla di loro.

Dobbiamo distinguere questi due tipi di eccezione in base se è programmatore di errore o non.

  • Se un errore è un programmatore di errore, deve essere una Eccezione Unchecked. Per esempio:SQLException/IOException/NullPointerException.Queste eccezioni sono errori di programmazione.Essi dovrebbero essere gestiti dal programmatore.Mentre in JDBC API, SQLException Eccezione Controllata, In Primavera JDBCTemplate si tratta di un'Eccezione Unchecked.Programmatore di non preoccuparsi SqlException, quando uso la Primavera.
  • Se un errore non è un programmatore di errore e il motivo è venuta dall'esterno, deve essere una Eccezione Controllata. Per esempio:se il il file viene eliminato o di autorizzazione del file è modificato da qualcun altro, dovrebbe essere recuperato.

FileNotFoundException è un buon esempio per capire le sottili differenze.FileNotFoundException è gettato nel caso in cui il file non viene trovato.Ci sono due motivi per questa eccezione.Se il percorso del file è definito dallo sviluppatore o assunzione dall'utente finale tramite la GUI dovrebbe essere una Eccezione Unchecked.Se il file viene eliminato da qualcun altro, dovrebbe essere una Eccezione Controllata.

Eccezione controllata può essere gestito in due modi.Questi stanno utilizzando try-catch o propagare l'eccezione.In caso di propagazione dell'eccezione, tutti i metodi di stack di chiamata sarà strettamente accoppiato a causa della gestione delle eccezioni.Ecco perché, dobbiamo usare Eccezione Controllata attentamente.

Nel caso In cui sviluppare un stratificato sistema di impresa, è necessario scegliere per lo più unchecked exception da buttare, ma non dimenticare di utilizzare controllato fatta eccezione per il caso non si può fare nulla.

Penso che quando si dichiara l'Eccezione dell'Applicazione dovrebbe essere Deselezionata Eccezione, cioè, sottoclasse di RuntimeException.Il motivo è che non ingombrano il codice dell'applicazione con try-catch e getta dichiarazione di metodo.Se l'applicazione utilizza Api Java che genera controllato eccezioni che comunque devono essere di gestire.Per gli altri casi, l'applicazione può lanciare eccezioni non controllata.Se l'applicazione chiamante deve ancora gestire eccezioni non controllata, può essere fatto.

La regola che uso io è:non utilizzare mai spuntata eccezioni!(o quando non si vede alcun modo intorno ad esso)

Dal punto di vista dello sviluppatore che utilizza la libreria o l'utente finale che utilizza la libreria/application fa davvero schifo a fare i conti con un'applicazione che si blocca a causa di un uncought eccezione.E contando su un catch-all è alcun bene.

In questo modo l'utente finale può ancora essere visualizzato un messaggio di errore, invece di applicazione del tutto scomparso.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top