Differenza tra java.lang.RuntimeException e java.lang.Exception

Qualcuno può spiegare la differenza tra java.lang.RuntimeException e java.lang.Exception ? Come posso decidere quale estendere se creo la mia eccezione?

Generalmente RuntimeException sono eccezioni che possono essere prevenute a livello di codice. Ad esempio NullPointerException , ArrayIndexOutOfBoundException . Se si verifica la presenza di null prima di chiamare qualsiasi metodo, NullPointerException non si verificherà mai. Allo stesso modo ArrayIndexOutOfBoundException non si verificherebbe mai se si controlla prima l’indice. RuntimeException non viene controllato dal compilatore, quindi è un codice pulito.

EDIT : in questi giorni le persone preferiscono RuntimeException perché il codice pulito produce. È una scelta totalmente personale.

In Java esistono due tipi di eccezioni: eccezioni controllate e eccezioni non spuntate. Un’eccezione controllata deve essere gestita esplicitamente dal codice, mentre un’eccezione non controllata non deve essere gestita esplicitamente.

Per le eccezioni controllate, devi mettere un blocco try / catch attorno al codice che potrebbe potenzialmente lanciare l’eccezione, o aggiungere una clausola “throws” al metodo, per indicare che il metodo potrebbe lanciare questo tipo di eccezione (che deve essere gestito nella class chiamante o superiore).

Qualsiasi eccezione derivante da “Eccezione” è un’eccezione controllata, mentre una class derivante da RuntimeException non è spuntata. Le RuntimeException non devono essere gestite esplicitamente dal codice chiamante.

Prima di esaminare la differenza tra le classi java.lang.RuntimeException e java.lang.Exception , è necessario conoscere la gerarchia Exception . Entrambe le classi Exception ed Error derivano dalla class Throwable (che deriva dalla class Object ). E la class RuntimeException deriva dalla class Exception .

Tutte le eccezioni sono derivate da Exception o RuntimeException .

Tutte le eccezioni che derivano da RuntimeException sono indicate come eccezioni non controllate . E tutte le altre eccezioni sono controllate eccezioni. Un’eccezione controllata deve essere catturata da qualche parte nel codice, altrimenti non verrà compilata. Questo è il motivo per cui vengono chiamate eccezioni controllate. D’altra parte, con le eccezioni non controllate, il metodo di chiamata non ha alcun obbligo di gestirlo o dichiararlo.

Pertanto tutte le eccezioni che il compilatore obbliga a gestire sono derivate direttamente da java.lang.Exception e tutte le altre che il compilatore non impone di gestire sono derivate da java.lang.RuntimeException .

Di seguito sono riportate alcune sottoclassi dirette di RuntimeException .

 AnnotationTypeMismatchException, ArithmeticException, ArrayStoreException, BufferOverflowException, BufferUnderflowException, CannotRedoException, CannotUndoException, ClassCastException, CMMException, ConcurrentModificationException, DataBindingException, DOMException, EmptyStackException, EnumConstantNotPresentException, EventException, IllegalArgumentException, IllegalMonitorStateException, IllegalPathStateException, IllegalStateException, ImagingOpException, IncompleteAnnotationException, IndexOutOfBoundsException, JMRuntimeException, LSException, MalformsdParameterizedTypeException, MirroredTypeException, MirroredTypesException, MissingResourceException, NegativeArraySizeException, NoSuchElementException, NoSuchMechanismException, NullPointerException, ProfileDataException, ProviderException, RasterFormatException, RejectedExecutionException, SecurityException, SystemException, TypeConstraintException, TypeNotPresentException, UndeclaredThrowableException, UnknownAnnotationValueException, UnknownElementException, UnknownTypeException, UnmodifiableSetException, UnsupportedOperationException, WebServiceException 

Un’eccezione è selezionata e una RuntimeException è deselezionata.

Selezionato significa che il compilatore richiede che tu gestisca l’eccezione in una cattura, o dichiari il tuo metodo come lanciarlo (o una delle sue superclassi).

Generalmente, lanciare un’eccezione controllata se si prevede che il chiamante dell’API gestisca l’eccezione e un’eccezione non controllata se è qualcosa che il chiamante normalmente non è in grado di gestire, come un errore con uno dei parametri, cioè una programmazione sbaglio.

Le classi di eccezione di runtime (RuntimeException e le sue sottoclassi) sono esentate dal controllo in fase di compilazione, poiché il compilatore non può stabilire che non possano verificarsi eccezioni di runtime. (da JLS).

Nelle classi che hai progettato dovresti creare una sottoclass di Exception e lanciare delle istanze per segnalare scenari eccezionali. In questo modo segnalerai esplicitamente ai clienti della tua class che l’utilizzo della tua class potrebbe generare un’eccezione e devono prendere provvedimenti per gestire questi scenari eccezionali.

I frammenti di codice seguenti spiegano questo punto:

 //Create your own exception class subclassing from Exception class MyException extends Exception { public MyException(final String message) { super(message); } } public class Process { public void execute() { throw new RuntimeException("Runtime"); } public void process() throws MyException { throw new MyException("Checked"); } } 

Nella suddetta definizione di class del processo di class, il metodo execute può lanciare un RuntimeException ma la dichiarazione del metodo non deve necessariamente specificare che restituisce RuntimeException .

Il process metodo genera un’eccezione controllata e deve dichiarare che genererà un’eccezione verificata di tipo MyException e che non lo farà sarà un errore di compilazione.

La precedente definizione della class influirà sul codice che utilizza anche la class Process .

La chiamata new Process().execute() è una chiamata valida dove come la chiamata di form new Process().process() dà un errore di compilazione. Ciò è dovuto al fatto che il codice client dovrebbe adottare misure per gestire MyException (ad esempio, call to process () può essere racchiuso in un blocco try / catch).

Uso corretto di RuntimeException?

Da Eccezioni non controllate – La polemica :

Se un cliente può ragionevolmente aspettarsi di recuperare da un’eccezione, renderlo un’eccezione controllata. Se un client non può eseguire operazioni di ripristino dall’eccezione, renderlo un’eccezione non controllata.

Si noti che un’eccezione non controllata è una derivata da RuntimeException e un’eccezione controllata è una derivata da Exception .

Perché lanciare un RuntimeException se un client non può eseguire operazioni di ripristino dall’eccezione? L’articolo spiega:

Le eccezioni di runtime rappresentano problemi che sono il risultato di un problema di programmazione e, come tale, il codice del client API non può ragionevolmente aspettarsi di recuperarli o gestirli in alcun modo. Tali problemi includono eccezioni aritmetiche, come la divisione per zero; eccezioni del puntatore, come provare ad accedere ad un object attraverso un riferimento null; e indicizzazione delle eccezioni, come ad esempio il tentativo di accedere a un elemento dell’array attraverso un indice troppo big o troppo piccolo.

Dalla documentazione di Oracle:

Ecco la linea di massima: se un cliente può ragionevolmente aspettarsi di recuperare da un’eccezione, rendilo un’eccezione controllata. Se un client non può eseguire operazioni di ripristino dall’eccezione, renderlo un’eccezione non controllata.

Le eccezioni del runtime rappresentano problemi che sono il risultato di un problema di programmazione e, come tale, il codice del client API non può ragionevolmente aspettarsi di recuperarli o gestirli in alcun modo.

Le eccezioni Runtime sono come “eccezioni per l’uso non valido di un API” esempi di runtimeexceptions: IllegalStateException, NegativeArraySizeException, NullpointerException

Con le eccezioni devi prenderlo esplicitamente perché puoi ancora fare qualcosa per recuperare. Esempi di eccezioni sono: IOException, TimeoutException, PrintException …

RuntimeException è una class figlia di class Exception

Questa è una delle tante classi child della class Exception. RuntimeException è la superclass di quelle eccezioni che possono essere generate durante il normale funzionamento della Java Virtual Machine. Non è richiesto un metodo per dichiarare nella sua clausola di derivazione qualsiasi sottoclass di RuntimeException che potrebbe essere lanciata durante l’esecuzione del metodo ma non catturata.

Il hierchy è

java.lang.Object

— java.lang.Throwable

——- java.lang.Exception

————- java.lang.RuntimeException

In parole semplici, se il client / utente può eseguire il ripristino dall’eccezione, renderlo un’eccezione verificata , se il client non può eseguire operazioni di ripristino dall’eccezione, quindi deselezionare RuntimeException deselezionata . Ad esempio, una RuntimeException sarebbe un errore programmatico, come la divisione per zero, nessun utente può fare nulla al riguardo ma il programmatore stesso, quindi è una RuntimeException .

Le eccezioni sono un buon modo per gestire eventi imprevisti nel stream delle applicazioni. RuntimeException è deselezionato dal compilatore ma potresti preferire utilizzare eccezioni che estendono la class Exception per controllare il comportamento dei tuoi client API in quanto sono necessari per rilevare gli errori da compilare. Inoltre forma una buona documentazione.

Se si desidera ottenere un’interfaccia pulita, utilizzare l’ereditarietà per creare una sottoclass dei diversi tipi di eccezioni presenti nell’applicazione e quindi esporre l’eccezione genitore.

Esistono due tipi di eccezione, È ansible ripristinare dall’eccezione controllata se si ottiene tale tipo di eccezione. Le eccezioni di runtime sono irrecuperabili, le eccezioni di runtime sono errori di programmazione e il programmatore dovrebbe occuparsene durante la scrittura del codice, e continuare l’esecuzione potrebbe fornire risultati errati. Le eccezioni del runtime riguardano la violazione della precondizione ex. hai una matrice di dimensione 10, e stai provando ad accedere all’11 ° elemento, genererà ArrayIndexOutOfBoundException

  1. Eccezione definita dall’utente può essere Eccezione controllata o Eccezione non verificata, dipende dalla class a cui si sta estendendo.

  2. L’eccezione definita dall’utente può essere l’eccezione controllata personalizzata, se si estende alla class Exception

  3. L’eccezione definita dall’utente può essere un’eccezione non selezionata personalizzata, se si estende alla class di eccezioni Run time.

  4. Definire una class e renderla un figlio per Eccezione o Eccezione di runtime