Risposte:
Generalmente RuntimeExceptions sono eccezioni che possono essere prevenute a livello di codice. Ad esempio NullPointerException, ArrayIndexOutOfBoundException. Se controlli nullprima di chiamare qualsiasi metodo, NullPointerExceptionnon si verificherebbe mai. Allo stesso modo ArrayIndexOutOfBoundExceptionnon si verificherebbe mai se si controlla prima l'indice. RuntimeExceptionnon sono controllati dal compilatore, quindi è un codice pulito.
EDIT : In questi giorni le persone preferiscono RuntimeExceptionperché il codice pulito che produce. È una scelta totalmente personale.
RuntimeExceptionè perché è semplice e ovvia alla necessità di pensare alle differenze tra eccezioni verificate e non verificate. Penso che catturare le eccezioni di runtime sia un'idea terribile perché catturerai eccezioni irrecuperabili come NullPointerException.
In Java, esistono due tipi di eccezioni: eccezioni verificate ed eccezioni non verificate. Un'eccezione controllata deve essere gestita in modo esplicito dal codice, mentre un'eccezione non selezionata non deve essere gestita in modo esplicito.
Per le eccezioni verificate, è necessario inserire un blocco try / catch attorno al codice che potrebbe potenzialmente generare l'eccezione oppure aggiungere una clausola "genera" al metodo, per indicare che il metodo potrebbe generare questo tipo di eccezione (che deve essere gestito nella classe chiamante o superiore).
Qualsiasi eccezione derivante da "Eccezione" è un'eccezione verificata, mentre una classe derivata da RuntimeException non è selezionata. Le RuntimeExceptions non devono essere gestite in modo esplicito dal codice chiamante.
Prima di osservare la differenza tra java.lang.RuntimeExceptione le java.lang.Exceptionclassi, devi conoscere la Exceptiongerarchia. Entrambe Exceptione le Errorclassi derivano dalla classe Throwable(che deriva dalla classe Object). E la classe RuntimeExceptionderiva dalla classe Exception.
Tutte le eccezioni sono derivate da Exceptiono RuntimeException.
Tutte le eccezioni da cui derivano RuntimeExceptionvengono definite eccezioni non controllate . E tutte le altre eccezioni sono controllate eccezioni. Un'eccezione verificata deve essere rilevata da qualche parte nel codice, altrimenti non verrà compilata. Ecco perché vengono chiamate eccezioni controllate. D'altra parte, con eccezioni non selezionate, il metodo di chiamata non ha l'obbligo di gestirlo o dichiararlo.
Pertanto, tutte le eccezioni che il compilatore ti obbliga a gestire derivano direttamente java.lang.Exceptione tutte le altre che il compilatore non ti obbligano a gestire derivano java.lang.RuntimeException.
Di seguito sono riportate alcune delle sottoclassi note 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,
MalformedParameterizedTypeException,
MirroredTypeException,
MirroredTypesException,
MissingResourceException,
NegativeArraySizeException,
NoSuchElementException,
NoSuchMechanismException,
NullPointerException,
ProfileDataException,
ProviderException,
RasterFormatException,
RejectedExecutionException,
SecurityException,
SystemException,
TypeConstraintException,
TypeNotPresentException,
UndeclaredThrowableException,
UnknownAnnotationValueException,
UnknownElementException,
UnknownTypeException,
UnmodifiableSetException,
UnsupportedOperationException,
WebServiceException Viene verificata un'eccezione e una RuntimeException non è selezionata.
Selezionato significa che il compilatore richiede che tu gestisca l'eccezione in una cattura o dichiari il tuo metodo come se lo lanciasse (o una delle sue superclasse).
Generalmente, genera un'eccezione controllata se si prevede che il chiamante dell'API gestirà l'eccezione e un'eccezione non selezionata se è qualcosa che il chiamante normalmente non sarebbe in grado di gestire, come un errore con uno dei parametri, ovvero una programmazione sbaglio.
Le classi di eccezioni di runtime (RuntimeException e le sue sottoclassi) sono esentate dal controllo del tempo di compilazione, poiché il compilatore non può stabilire che non possono verificarsi eccezioni di runtime. (da JLS).
Nelle classi progettate dovresti sottoclassare l' eccezione e lanciarne istanze per segnalare scenari eccezionali. In questo modo segnalerai esplicitamente ai clienti della tua classe che l'utilizzo della tua classe potrebbe generare eccezioni e che dovranno prendere provvedimenti per gestire quegli scenari eccezionali.
Di seguito i frammenti di codice 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 definizione di classe sopra della classe Process , il metodo executepuò generare una RuntimeException ma la dichiarazione del metodo non deve specificare che genera RuntimeException .
Il metodo processgenera un'eccezione controllata e dovrebbe dichiarare che genererà un'eccezione controllata del tipo MyException e non farlo sarà un errore di compilazione.
La definizione della classe precedente influirà anche sul codice che utilizza la classe Process .
La chiamata new Process().execute()è una chiamata valida in cui la chiamata del modulo
new Process().process()genera un errore di compilazione. Questo perché il codice client dovrebbe prendere delle misure da gestire MyException(diciamo che call to process () può essere racchiuso in un blocco try / catch).
L'uso corretto di RuntimeException?
Dalle eccezioni non controllate - The Controversy :
Se ci si può ragionevolmente aspettare che un client si ripristini da un'eccezione, renderlo un'eccezione controllata. Se un client non può fare nulla per ripristinare l'eccezione, impostalo come un'eccezione non selezionata.
Si noti che un'eccezione non selezionata è derivata da RuntimeExceptionun'eccezione verificata Exception.
Perché lanciare un RuntimeExceptionse un client non può fare nulla per recuperare dall'eccezione? L'articolo spiega:
Le eccezioni di runtime rappresentano problemi che sono il risultato di un problema di programmazione e, come tale, non ci si può ragionevolmente aspettare che il codice client dell'API si ripristini da loro o li gestisca in alcun modo. Tali problemi includono eccezioni aritmetiche, come la divisione per zero; eccezioni del puntatore, come il tentativo di accedere a un oggetto tramite un riferimento null; e eccezioni di indicizzazione, come il tentativo di accedere a un elemento dell'array tramite un indice troppo grande o troppo piccolo.
Dalla documentazione di Oracle:
Ecco la linea di fondo: se un cliente può ragionevolmente aspettarsi di recuperare da un'eccezione, impostalo come un'eccezione controllata. Se un client non può fare nulla per ripristinare l'eccezione, impostalo come un'eccezione non selezionata.
Le eccezioni di runtime rappresentano problemi che sono il risultato di un problema di programmazione e, come tale, non ci si può ragionevolmente aspettare che il codice client dell'API si ripristini da loro o li gestisca in alcun modo.
RuntimeExceptions sono come "eccezioni per 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 ...
In parole semplici, se il cliente / utente può recuperare dal Exception poi ne fanno un Controllato eccezione , se il cliente non può fare nulla per recuperare dalla Exception poi ne fanno non controllato RuntimeException . Ad esempio, una RuntimeException sarebbe un errore programmatico, come la divisione per zero, nessun utente può farci nulla tranne il programmatore stesso, quindi è una RuntimeException .
RuntimeException è una classe figlio della classe Exception
Questa è una delle molte classi secondarie della classe Exception. RuntimeException è la superclasse di quelle eccezioni che possono essere generate durante il normale funzionamento di Java Virtual Machine. Non è necessario un metodo per dichiarare nella clausola dei suoi tiri eventuali sottoclassi di RuntimeException che potrebbero essere generate durante l'esecuzione del metodo ma non rilevate.
Lo è
java.lang.Object
--- java.lang.Throwable
------- java.lang.Exception
------------- java.lang.RuntimeException
Le eccezioni sono un buon modo per gestire eventi imprevisti nel flusso dell'applicazione. RuntimeException non è selezionata dal compilatore, ma potresti preferire utilizzare le eccezioni che estendono la classe di eccezione per controllare il comportamento dei tuoi client API in quanto sono tenuti a rilevare errori per la compilazione. Forma anche una buona documentazione.
Se si desidera ottenere un'interfaccia pulita, utilizzare l'ereditarietà per sottoclassare i diversi tipi di eccezione dell'applicazione e quindi esporre l'eccezione principale.
Esistono due tipi di eccezione, è possibile ripristinare l'eccezione selezionata se si ottiene questo 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 di questo potrebbe dare risultati errati. Le eccezioni di runtime riguardano la violazione di precondizioni ex. hai un array di dimensioni 10 e stai provando ad accedere all'11 ° elemento, genererà ArrayIndexOutOfBoundException
L'eccezione definita dall'utente può essere Eccezione controllata o Eccezione non selezionata, dipende dalla classe a cui si sta estendendo.
L'eccezione definita dall'utente può essere un'eccezione controllata personalizzata, se si estende alla classe Exception
L'eccezione definita dall'utente può essere un'eccezione non selezionata personalizzata, se si estende alla classe Eccezione di runtime.
Definire una classe e renderla figlio di Eccezione o Eccezione di runtime