has - Diferencia entre java.lang.RuntimeException y java.lang.Exception
throw exception java (12)
¿Alguien por favor explique la diferencia entre java.lang.RuntimeException y java.lang.Exception ? ¿Cómo decido cuál extender si creo mi propia excepción?
Excepción definida por el usuario puede ser Excepción marcada o Excepción no verificada, depende de la clase a la que se extiende.
Excepción definida por el usuario puede ser Excepción marcada personalizada, si se extiende a la clase Excepción
La excepción definida por el usuario puede ser una excepción no verificada, si se extiende a la clase de excepción de tiempo de ejecución.
Defina una clase y conviértalo en un niño para Exception o Run time Exception
Antes de analizar la diferencia entre las clases java.lang.RuntimeException y java.lang.Exception , debe conocer la jerarquía de Exception . Ambas clases de Exception y Error se derivan de la clase Throwable (que se deriva de la clase Object ). Y la clase RuntimeException se deriva de la clase Exception .
Todas las excepciones se derivan de Exception o RuntimeException .
Todas las excepciones que se derivan de RuntimeException se conocen como excepciones sin marcar. Y todas las demás excepciones son excepciones marcadas . Una excepción marcada debe capturarse en algún lugar de su código; de lo contrario, no se compilará. Es por eso que se llaman excepciones marcadas. Por otro lado, con excepciones no verificadas, el método de llamada no está bajo la obligación de manejarlo o declararlo.
Por lo tanto, todas las excepciones que el compilador obliga a manejar se derivan directamente de java.lang.Exception y todas las otras que el compilador no lo fuerza a manejar se derivan de java.lang.RuntimeException .
A continuación, se incluyen algunas de las subclases conocidas 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
De la documentación del oráculo:
Aquí está la pauta de la línea inferior: si se puede esperar razonablemente que un cliente se recupere de una excepción, conviértalo en una excepción marcada. Si un cliente no puede hacer nada para recuperarse de la excepción, conviértalo en una excepción no verificada.
Las excepciones de tiempo de ejecución representan problemas que son el resultado de un problema de programación y, como tal, no se puede esperar razonablemente que el código del cliente API se recupere de ellos o que los maneje de ninguna manera.
RuntimeExceptions es como "excepciones por uso no válido de una API" ejemplos de runtimeexceptions: IllegalStateException, NegativeArraySizeException, NullpointerException
Con las Excepciones debes atraparlo de forma explícita porque aún puedes hacer algo para recuperarlo. Ejemplos de excepciones son: IOException, TimeoutException, PrintException ...
En Java, hay dos tipos de excepciones: excepciones marcadas y excepciones no verificadas. El código debe manejar explícitamente una excepción comprobada, mientras que una excepción no verificada no necesita ser tratada explícitamente.
Para las excepciones comprobadas, debe colocar un bloque try / catch alrededor del código que potencialmente podría arrojar la excepción, o agregar una cláusula "throws" al método, para indicar que el método podría arrojar este tipo de excepción (que debe ser manejado en la clase de llamada o superior).
Cualquier excepción que se derive de "Excepción" es una excepción comprobada, mientras que una clase que se deriva de RuntimeException no está marcada. RuntimeExceptions no necesita ser manejado explícitamente por el código de llamada.
En general, RuntimeExceptions son excepciones que pueden evitarse mediante programación. Por ejemplo, NullPointerException , ArrayIndexOutOfBoundException . Si comprueba null antes de llamar a cualquier método, NullPointerException nunca ocurrirá. De ArrayIndexOutOfBoundException similar, ArrayIndexOutOfBoundException nunca ocurriría si primero se verifica el índice. RuntimeException no son verificados por el compilador, por lo que es un código limpio.
EDITAR : En estos días las personas RuntimeException porque el código de limpieza que produce. Es una elección totalmente personal.
En palabras simples, si su cliente / usuario puede recuperarse de la Excepción, conviértalo en una Excepción Controlada , si su cliente no puede hacer nada para recuperarse de la Excepción, entonces conviértalo en una Excepción de Tiempo Descomprimido . Por ejemplo, una RuntimeException sería un error de programación, como división por cero, ningún usuario puede hacer nada al respecto sino el propio programador, entonces es una RuntimeException .
Hay dos tipos de excepción: Puede recuperar de la excepción marcada si obtiene ese tipo de excepción. La excepción de tiempo de ejecución es irrecuperable, las excepciones de tiempo de ejecución son errores de programación, y el programador debe ocuparse de ello mientras escribe el código, y continuar la ejecución de esto podría darle un resultado incorrecto. Las excepciones de tiempo de ejecución se refieren a la violación de la precondición, por ejemplo. tienes una matriz de tamaño 10, y estás tratando de acceder al 11º elemento, lanzará ArrayIndexOutOfBoundException
Las clases de excepción de 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 las excepciones en tiempo de ejecución no pueden ocurrir. (de JLS).
En las clases que diseñe, debe subclase Excepción y lanzar instancias para señalar cualquier escenario excepcional. Al hacerlo, señalará explícitamente a los clientes de su clase que el uso de su clase podría arrojar una excepción y que deben tomar medidas para manejar esos escenarios excepcionales.
A continuación, los 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 Class Process , el método execute puede arrojar una RuntimeException pero la declaración de método no necesita especificar que lanza RuntimeException .
El process método arroja una excepción marcada y debe declarar que arrojará una excepción marcada del tipo MyException y no hacerlo será un error de compilación.
La definición de clase anterior afectará también al código que usa la clase Process .
La llamada new Process().execute() es una invocación válida donde como la llamada de forma new Process().process() da un error de compilación. Esto se debe a que el código del cliente debe tomar medidas para manejar MyException (digamos que call to process () se puede encerrar en un bloque try / catch).
Las excepciones son una buena forma de manejar eventos inesperados en el flujo de su aplicación. RuntimeException no está seleccionada por el Compilador, pero es posible que prefiera usar Excepciones que extiendan la Clase de excepción para controlar el comportamiento de sus clientes api, ya que son necesarios para detectar errores y compilarlos. También forma una buena documentación.
Si desea lograr una interfaz limpia, use la herencia para clasificar los diferentes tipos de excepción que tiene su aplicación y luego exponga la excepción padre.
RuntimeException es una clase hija de la clase Exception
Esta es una de las muchas clases secundarias de la clase Excepción. RuntimeException es la superclase de las excepciones que se pueden lanzar durante el funcionamiento normal de la máquina virtual Java. No se requiere un método para declarar en su cláusula throws ninguna subclase de RuntimeException que pueda arrojarse durante la ejecución del método pero que no sea capturada.
El hierchy es
java.lang.Object
--- java.lang.Throwable
------- java.lang.Exception
------------- java.lang.RuntimeException
Se verifica una excepción y una excepción RuntimeException está desmarcada.
Controlado significa que el compilador requiere que maneje la excepción en una captura, o declare su método como arrojándolo (o una de sus superclases).
En general, arroje una excepción marcada si se espera que el llamante de la API maneje la excepción, y una excepción sin marcar si es algo que la persona que llama normalmente no podría manejar, como un error con uno de los parámetros, es decir, una programación Error.
Uso apropiado de RuntimeException?
Desde excepciones no verificadas: la controversia :
Si es razonable esperar que un cliente se recupere de una excepción, conviértalo en una excepción marcada. Si un cliente no puede hacer nada para recuperarse de la excepción, conviértalo en una excepción no verificada.
Tenga en cuenta que una excepción sin marcar es una derivada de RuntimeException y una excepción marcada es una derivada de Exception .
¿Por qué lanzar una RuntimeException si un cliente no puede hacer nada para recuperarse de la excepción? El artículo explica:
Las excepciones de tiempo de ejecución representan problemas que son el resultado de un problema de programación y, como tal, no se puede esperar razonablemente que el código del cliente API se recupere de ellos o que los maneje de ninguna manera. Dichos problemas incluyen excepciones aritméticas, como dividir por cero; excepciones de puntero, como intentar acceder a un objeto a través de una referencia nula; e indexar excepciones, como intentar acceder a un elemento de matriz a través de un índice que es demasiado grande o demasiado pequeño.