Diferencia entre java.lang.RuntimeException y java.lang.Exception
Alguien por favor explique la diferencia entre java.lang.RuntimeExceptiony java.lang.Exception? ¿Cómo decido cuál extender si creo mi propia excepción?
Generalmente, las RuntimeExceptions son excepciones que se pueden prevenir mediante programación. P.ej NullPointerException, ArrayIndexOutOfBoundException. Si verifica nullantes de llamar a cualquier método, NullPointerExceptionnunca ocurriría. Nunca ocurriría lo mismo ArrayIndexOutOfBoundExceptionsi primero verifica el índice. RuntimeExceptionEl compilador no los verifica, por lo que es un código limpio.
EDITAR : Hoy en día la gente prefiere RuntimeExceptionel código limpio que produce. Es una elección totalmente personal.
En Java, existen dos tipos de excepciones: excepciones marcadas y excepciones no marcadas. Una excepción marcada debe ser manejada explícitamente por el código, mientras que una excepción no marcada no necesita ser manejada explícitamente.
Para las excepciones marcadas, debe colocar un bloque try/catch alrededor del código que potencialmente podría generar la excepción, o agregar una cláusula "throws" al método para indicar que el método podría generar este tipo de excepción (que debe ser manejado en la clase de llamada o superior).
Cualquier excepción que se derive de "Exception" es una excepción marcada, mientras que una clase que se deriva de RuntimeException no está marcada. No es necesario que el código de llamada maneje explícitamente las RuntimeExceptions.
Antes de ver la diferencia entre clases java.lang.RuntimeExceptiony java.lang.Exception, debes conocer la Exceptionjerarquía. Tanto Exceptionlas Errorclases como se derivan de la clase Throwable(que deriva de la clase Object). Y la clase RuntimeExceptionse deriva de class Exception.
Todas las excepciones se derivan de Exceptiono RuntimeException.
Todas las excepciones que se derivan de RuntimeExceptionse denominan excepciones no comprobadas . Y todas las demás excepciones son excepciones marcadas . Una excepción marcada debe detectarse en algún lugar de su código; de lo contrario, no se compilará. Por eso se denominan excepciones comprobadas. Por otro lado, salvo excepciones no comprobadas, el método que llama no tiene la obligación de manejarlo o declararlo.
Por lo tanto, todas las excepciones que el compilador le obliga a manejar se derivan directamente de java.lang.Exceptiony todas las demás que el compilador no le obliga a manejar se derivan de java.lang.RuntimeException.
A continuación se muestran algunas de las subclases conocidas directamente de 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
Una Exceptionestá marcada y una RuntimeExceptionno está marcada.
Marcado significa que el compilador requiere que manejes la excepción en un catch, o que declares tu método como lanzador (o una de sus superclases).
Generalmente, lanza una excepción marcada si se espera que la persona que llama de la API maneje la excepción, y una excepción no marcada si es algo que la persona que llama normalmente no podría manejar, como un error con uno de los parámetros, es decir, un error de programación. error.
Las clases de excepción en tiempo de ejecución (RuntimeException y sus subclases) están exentas de la verificación en tiempo de compilación, ya que el compilador no puede establecer que no puedan ocurrir excepciones en tiempo de ejecución. (de JLS).
En las clases que diseñe, debe subclasificar Exception y generar instancias de la misma para señalar cualquier escenario excepcional. Al hacerlo, indicará explícitamente a los clientes de su clase que el uso de su clase podría generar una excepción y que deben tomar medidas para manejar esos escenarios excepcionales.
Los siguientes fragmentos de código explican este 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");
}
}
En la definición de clase anterior de la clase Process , el método executepuede lanzar una RuntimeException pero la declaración del método no necesita especificar que arroja RuntimeException .
El método processarroja una excepción marcada y debe declarar que arrojará una excepción marcada del tipo MyException y que no hacerlo será un error de compilación.
La definición de clase anterior también afectará el código que usa la clase Proceso .
La llamada new Process().execute()es una invocación válida donde la llamada del formulario
new Process().process()genera un error de compilación. Esto se debe a que el código del cliente debe tomar medidas para manejarlo MyException(por ejemplo, la llamada al proceso() puede incluirse en un bloque try/catch).
