Domanda

La maggior parte del tempo userò un'eccezione per verificare la presenza di una condizione nel mio codice, mi chiedo quando è il momento giusto per usare un'affermazione?

Per esempio,

Group group=null;
try{
    group = service().getGroup("abc");
}catch(Exception e){
    //I dont log error because I know whenever error occur mean group not found
}

if(group !=null)
{
    //do something
}

Potrebbe indicare come un'asserzione si inserisce qui? Dovrei usare un'affermazione?

Sembra che io non uso mai le asserzioni nel codice di produzione e vedo solo asserzioni di test di unità. So che nella maggior parte dei casi, posso solo usare eccezioni per fare il controllo, come sopra, ma io voglio sapere modo appropriato per farlo "professionalmente".

È stato utile?

Soluzione

Le asserzioni devono essere utilizzati per controllare qualcosa che non dovrebbe mai accadere, mentre un'eccezione dovrebbe essere utilizzato per controllare qualcosa che potrebbe accadere.

Per esempio, una funzione potrebbe dividere per 0, quindi un'eccezione deve essere utilizzato, ma un'affermazione potrebbe essere utilizzato per verificare che il disco rigido scompare improvvisamente.

Un'affermazione sarebbe fermata l'esecuzione del programma, ma un'eccezione sarebbe lasciare che il programma continuerà a funzionare.

Si noti che if(group != null) non è un'affermazione, che è solo un condizionale.

Altri suggerimenti

Out of my mind (lista potrebbe essere incompleta, ed è troppo lungo per essere contenuto in un commento), direi:

  • uso eccezioni quando controllo parametri passati ai metodi e costruttori pubblici o protetti
  • utilizzare le eccezioni durante l'interazione con l'utente o quando ci si aspetta il codice del client per recuperare da una situazione eccezionale
  • utilizzare le eccezioni per affrontare i problemi che si potrebbero verificare
  • uso affermazioni durante il controllo pre-condizioni, post-condizioni e invarianti di codice privato / interno
  • uso affermazioni per fornire un feedback a voi stessi o il vostro team di sviluppo
  • uso affermazioni durante il controllo per le cose che sono molto improbabile che accada altrimenti vuol dire che v'è una grave fl aw nell'applicazione
  • uso affermazioni a cose di stato che (presumibilmente) sappiamo essere vero

In altre parole, le eccezioni affrontare la robustezza della vostra applicazione, mentre le affermazioni affrontare la sua correttezza.

Le asserzioni sono progettati per essere a buon mercato di scrivere, si possono usare quasi ovunque e sto usando questa regola: tanto più una dichiarazione affermazione sembra stupido, il più prezioso che è e più informazioni che incorpora. Quando il debug di un programma che non si comporta nel modo giusto, sarà sicuramente verificare le possibilità di fallimento più evidente, sulla base di esperienza. Poi si verifica la presenza di problemi che proprio non può accadere:. Questo è esattamente quando affermazioni aiutano molto e risparmiare tempo

Ricorda affermazioni possono essere disabilitati in fase di esecuzione utilizzando i parametri, e sono disabilitati di default , quindi non contare su di loro tranne che per scopi di debug.

Inoltre si dovrebbe leggere il articolo Oracle su assert per vedere più casi in cui da usare - o non usare -. assert

Come regola generale:

  • Utilizzare asserzioni di controlli di coerenza interna, dove non importa affatto se qualcuno li spegne. (Si noti che il comando java disattiva tutte le asserzioni di default.)
  • Utilizza test regolari per qualsiasi tipo di controlli di ciò che non dovrebbe essere spento. Questo include controlli difensivi che proteggono contro il potenziale causa danni da insetti e tutti i dati di validazione / le domande / qualunque forniti dagli utenti o servizi esterni.

Il seguente codice tua domanda è cattivo stile e potenzialmente buggy

try {
    group = service().getGroup("abc");
} catch (Exception e) {
    //i dont log error because i know whenever error occur mean group not found
}

Il problema è che non si sa che un'eccezione significa che il gruppo non è stato trovato. E 'anche possibile che la chiamata service() ha generato un'eccezione, o che ha restituito null che poi ha causato un NullPointerException.

Quando si cattura un'eccezione "atteso", si dovrebbe prendere solo l'eccezione che vi aspettate. Con la cattura di java.lang.Exception (e soprattutto da non accedendo esso), si stanno facendo più difficile da diagnosticare / debug del problema, e, potenzialmente, consentendo l'applicazione per fare più danni.

In base a questo documento http://docs.oracle.com/javase/6/docs/technotes/guides/language/assert.html#design-faq-general , "L'istruzione assert è appropriato per precondizione non pubbliche, postcondition e invariante di classe controllo. controllo presupposto pubblico dovrebbe comunque essere effettuata da controlli all'interno di metodi che si traducono in particolare, le eccezioni documentate, quali IllegalArgumentException e IllegalStateException ".

Se vuoi sapere di più su precondizione, postcondition e invariante di classe, controllare questo documento: http://docs.oracle.com/javase/6/docs/technotes/guides/language/assert.html#usage-conditions . Contiene anche con esempi di utilizzo asserzioni.

Bene, torniamo a Microsoft, la raccomandazione è stato quello di generare eccezioni in tutte le API a rendere disponibili al pubblico e l'uso asserisce in ogni sorta di ipotesi che si fanno sul codice che è interna. E 'un po' di una definizione sciolto ma immagino che tocca a ogni sviluppatore per disegnare la linea.

Per quanto riguarda l'uso di eccezioni, come dice il nome, il loro uso dovrebbe essere eccezionale così per il codice è presente al di sopra, la chiamata getGroup deve restituire null se non esiste alcun servizio. Eccezione deve avvenire solo se un collegamento di rete va giù o qualcosa del genere.

Credo che la conclusione è che è un po 'a sinistra in fondo al team di sviluppo per ogni applicazione per definire i confini della assert vs eccezioni.

Test per nulla cattura solo i null causando problemi, mentre un try / catch, come lo avete prenderà qualsiasi di errore.

In linea di massima, try / catch è più sicuro, ma leggermente più lento, e bisogna stare attenti che si cattura tutti i tipi di errore che possono verificarsi. Quindi direi uso try / catch -. Un giorno il codice di getGroup può cambiare, e basta avere bisogno che più grande rete

È possibile utilizzare questo semplice differenza in mente, mentre il loro utilizzo. Le eccezioni saranno utilizzati per il controllo degli errori previsti e errori imprevisti chiamati controllati e incontrollato, mentre asserzione viene utilizzato principalmente per scopi di debugging in fase di esecuzione per vedere se le ipotesi sono convalidate o meno.

Confesso che sono un po 'confuso per la tua domanda. Quando una condizione di asserzione non è soddisfatta, viene generata un'eccezione. Confusamente questo si chiama AssertionError . Si noti che è senza controllo, come (per esempio) IllegalArgumentException , che viene gettato in circostanze molto simili.

Quindi, utilizzando affermazioni in Java

  1. è un mezzo più concisa di scrittura di un blocco di condizione / tiro
  2. permette di trasformare questi controlli on / off tramite parametri JVM. Normalmente avrei lasciare queste verifiche in tutto il tempo, a meno che non influire sulle prestazioni di esecuzione o di avere un rigore simile.

Si veda la sezione 6.1.2 (asserzioni vs. altro codice di errore) della documentazione di Sun al seguente link.

http://www.oracle.com/technetwork/articles/javase/ javapch06.pdf

Questo documento fornisce il miglior consiglio che ho visto su quando utilizzare le asserzioni. Citando dal documento:

"Una buona regola generale è che si dovrebbe usare un'affermazione per casi eccezionali che si desidera di dimenticare. Un'affermazione è il modo più rapido per affrontare, e dimenticare, una condizione o stato che non ti aspetti avere a che fare con ".

Purtroppo asserisce può essere disabilitato. Quando nella produzione avete bisogno di tutto l'aiuto che si può ottenere quando rintracciare qualcosa di imprevisto, così afferma squalificare se stessi.

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