Comprender las excepciones marcadas y no marcadas en Java

Joshua Bloch en " Java efectivo " dijo que

Use excepciones marcadas para condiciones recuperables y excepciones de tiempo de ejecución para errores de programación (Elemento 58 en la 2da edición)

A ver si entiendo esto correctamente.

Aquí está mi comprensión de una excepción marcada:

try{
    String userInput = //read in user input
    Long id = Long.parseLong(userInput);
}catch(NumberFormatException e){
    id = 0; //recover the situation by setting the id to 0
}

1. ¿Se considera lo anterior como una excepción marcada?

2. ¿RuntimeException es una excepción no verificada?

Aquí está mi comprensión de una excepción no marcada:

try{
    File file = new File("my/file/path");
    FileInputStream fis = new FileInputStream(file);   
}catch(FileNotFoundException e){

//3. What should I do here?
    //Should I "throw new FileNotFoundException("File not found");"?
    //Should I log?
    //Or should I System.exit(0);?
}

4. Ahora, ¿no podría el código anterior ser también una excepción marcada? ¿Puedo intentar recuperar la situación así? ¿Puedo? (Nota: mi tercera pregunta está dentro de lo catchanterior)

try{
    String filePath = //read in from user input file path
    File file = new File(filePath);
    FileInputStream fis = new FileInputStream(file);   
}catch(FileNotFoundException e){
    //Kindly prompt the user an error message
    //Somehow ask the user to re-enter the file path.
}

5. ¿Por qué la gente hace esto?

public void someMethod throws Exception{

}

¿Por qué dejan que la excepción brote? ¿No es mejor manejar el error antes? ¿Por qué burbujear?

6. ¿Debo burbujear la excepción exacta o enmascararla usando Exception?

Abajo están mis lecturas

En Java, ¿cuándo debería crear una excepción marcada y cuándo debería ser una excepción de tiempo de ejecución?

Cuándo elegir excepciones marcadas y no marcadas

Mucha gente dice que las excepciones marcadas (es decir, las que debe capturar o volver a lanzar explícitamente) no deben utilizarse en absoluto. Se eliminaron en C #, por ejemplo, y la mayoría de los idiomas no los tienen. Por lo tanto, siempre puede lanzar una subclase de RuntimeException(excepción no marcada)

Sin embargo, creo que las excepciones comprobadas son útiles: se usan cuando desea obligar al usuario de su API a pensar cómo manejar la situación excepcional (si es recuperable). Es solo que las excepciones marcadas se usan en exceso en la plataforma Java, lo que hace que las personas las odien.

Aquí está mi visión extendida sobre el tema .

En cuanto a las preguntas particulares:

1. ¿Es el NumberFormatExceptionconsiderar una excepción marcada?
   No. NumberFormatExceptionno está marcado (= es una subclase de RuntimeException). ¿Por qué? No lo sé. (pero debería haber habido un método isValidInteger(..))

2. ¿Es RuntimeExceptionuna excepción no verificada?
   Sí exactamente.

3. ¿Qué debo hacer aquí?
   Depende de dónde esté este código y de lo que quieras que suceda. Si está en la capa de la interfaz de usuario, atrápelo y muestre una advertencia; si está en la capa de servicio, no la atrape en absoluto, déjela burbujear. Simplemente no te tragues la excepción. Si ocurre una excepción en la mayoría de los casos, debe elegir uno de estos:

   • iniciar sesión y volver
   • volver a tirarlo (declararlo por el método)
   • construir una nueva excepción pasando la actual en el constructor

4. Ahora, ¿no podría el código anterior también ser una excepción marcada? ¿Puedo intentar recuperar la situación así? ¿Puedo?
   Pudo haber sido. Pero nada le impide captar la excepción no verificada también

5. ¿Por qué la gente agrega clase Exceptionen la cláusula throws?
   Muy a menudo porque las personas son flojas para considerar qué atrapar y qué volver a lanzar. Lanzar Exceptiones una mala práctica y debe evitarse.

Por desgracia, no existe una regla única que le permita determinar cuándo atrapar, cuándo volver a lanzar, cuándo usar las excepciones marcadas y cuándo no controladas. Estoy de acuerdo en que esto causa mucha confusión y mucho código incorrecto. Bloch establece el principio general (usted citó una parte de él). Y el principio general es volver a lanzar una excepción a la capa donde puede manejarla.

Si algo es una "excepción marcada" no tiene nada que ver con si lo atrapa o qué hace en el bloque de captura. Es una propiedad de las clases de excepción. Todo lo que es una subclase de Exception excepción para el RuntimeExceptiony sus subclases es una excepción comprobada.

El compilador de Java te obliga a capturar excepciones comprobadas o declararlas en la firma del método. Se suponía que mejoraría la seguridad del programa, pero la opinión mayoritaria parece ser que no vale la pena los problemas de diseño que crea.

¿Por qué dejan que la excepción brote? ¿No se maneja el error cuanto antes mejor? ¿Por qué burbujear?

Porque ese es todo el punto de excepciones. Sin esta posibilidad, no necesitaría excepciones. Le permiten manejar errores en el nivel que elija, en lugar de obligarlo a tratarlos en métodos de bajo nivel donde ocurren originalmente.

1. ¿Se considera lo anterior como una excepción marcada? No El hecho de que esté manejando una excepción no lo convierte en un Checked Exceptionsi es un RuntimeException.

2. Es RuntimeExceptionun unchecked exception? si

Checked Exceptionsson subclassesde java.lang.Exception Unchecked Exceptionsson subclassesdejava.lang.RuntimeException

Las llamadas que arrojan excepciones comprobadas deben incluirse en un bloque try {} o manejarse en un nivel superior en la persona que llama del método. En ese caso, el método actual debe declarar que arroja dichas excepciones para que los llamantes puedan hacer los arreglos apropiados para manejar la excepción.

Espero que esto ayude.

P: ¿debo hacer burbujear la excepción exacta o enmascararla usando Exception?

R: Sí, esta es una muy buena pregunta y una importante consideración de diseño. La clase Exception es una clase de excepción muy general y se puede usar para ajustar excepciones internas de bajo nivel. Será mejor que crees una excepción personalizada y la envuelvas dentro. Pero, y uno grande: nunca oculte la causa raíz original subyacente. Por ejemplo, Don't everhaz lo siguiente:

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException("Cannot login!!"); //<-- Eat away original root cause, thus obscuring underlying problem.
}

En su lugar, haga lo siguiente:

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException(sqle); //<-- Wrap original exception to pass on root cause upstairs!.
}

La eliminación de la causa raíz original entierra la causa real más allá de la recuperación es una pesadilla para los equipos de soporte de producción, a los que solo tienen acceso los registros de aplicaciones y los mensajes de error. Aunque este último es un mejor diseño, muchas personas no lo usan a menudo porque los desarrolladores simplemente no transmiten el mensaje subyacente a la persona que llama. Por lo tanto, tome una nota firme: Always pass on the actual exceptionretroceda si está envuelto o no en una excepción específica de la aplicación.

Al intentar atrapar RuntimeExceptions

RuntimeExceptions como regla general no debe ser probado. Generalmente señalan un error de programación y deben dejarse solos. En cambio, el programador debe verificar la condición de error antes de invocar algún código que pueda resultar en un RuntimeException. Por ej .:

try {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welcome to my site!);
} catch (NullPointerException npe) {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

Esta es una mala práctica de programación. En cambio, un cheque nulo debería haberse hecho como:

if (userObject != null) {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome to my site!);
} else {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

Pero hay momentos en que dicha comprobación de errores es costosa, como el formato de números, considere esto:

try {
    String userAge = (String)request.getParameter("age");
    userObject.setAge(Integer.parseInt(strUserAge));
} catch (NumberFormatException npe) {
   sendError("Sorry, Age is supposed to be an Integer. Please try again.");
}

Aquí la comprobación de errores previa a la invocación no vale la pena porque esencialmente significa duplicar todo el código de conversión de cadena a entero dentro del método parseInt (), y es propenso a errores si lo implementa un desarrollador. Por lo tanto, es mejor eliminar el try-catch.

Entonces, NullPointerExceptiony NumberFormatExceptionambos son RuntimeExceptions, la captura de un NullPointerExceptiondebería reemplazarse con una elegante comprobación nula, mientras que recomiendo capturar NumberFormatExceptionexplícitamente para evitar la posible introducción de código propenso a errores.

1) Si no está seguro acerca de una excepción, verifique la API:

 java.lang.Object
 extended by java.lang.Throwable
  extended by java.lang.Exception
   extended by java.lang.RuntimeException  //<-NumberFormatException is a RuntimeException  
    extended by java.lang.IllegalArgumentException
     extended by java.lang.NumberFormatException

2) Sí, y cada excepción que lo extiende.

3) No hay necesidad de atrapar y lanzar la misma excepción. Puede mostrar un nuevo cuadro de diálogo de archivo en este caso.

4) FileNotFoundException ya es una excepción marcada.

5) Si se espera que el método que llama someMethodpara atrapar la excepción, este último pueda ser lanzado. Simplemente "pasa la pelota". Un ejemplo de su uso sería si desea incluirlo en sus propios métodos privados y manejar la excepción en su método público.

Una buena lectura es el documento de Oracle: http://download.oracle.com/javase/tutorial/essential/exceptions/runtime.html

¿Por qué los diseñadores decidieron forzar un método para especificar todas las excepciones comprobadas no detectadas que se pueden lanzar dentro de su alcance? Cualquier excepción que pueda generar un método es parte de la interfaz de programación pública del método. Aquellos que llaman a un método deben conocer las excepciones que puede lanzar un método para poder decidir qué hacer al respecto. Estas excepciones son tan parte de la interfaz de programación de ese método como sus parámetros y valor de retorno.

La siguiente pregunta podría ser: "Si es tan bueno documentar la API de un método, incluidas las excepciones que puede generar, ¿por qué no especificar excepciones de tiempo de ejecución también?" 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 los maneje de ninguna manera. Tales 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 excepciones de indexación, como intentar acceder a un elemento de matriz a través de un índice que es demasiado grande o demasiado pequeño.

También hay un poco de información importante en la Especificación del lenguaje Java :

Las clases de excepción marcadas nombradas en la cláusula throws son parte del contrato entre el implementador y el usuario del método o constructor .

La conclusión en mi humilde opinión es que puede atrapar cualquiera RuntimeException, pero no está obligado a hacerlo y, de hecho, la implementación no está obligada a mantener las mismas excepciones no verificadas, ya que no forman parte del contrato.

1) No, un NumberFormatException es una excepción no marcada. A pesar de que lo atrapó (no es obligatorio) porque no está marcado. Esto se debe a que es una subclase de la IllegalArgumentExceptioncual es una subclase de RuntimeException.

2) RuntimeExceptiones la raíz de todas las Excepciones no marcadas. Cada subclase de RuntimeExceptionestá desmarcada. Todas las demás excepciones y Throwablese verifican, excepto los errores (que se detallan a continuación Throwable).

3/4) Puede alertar al usuario de que eligió un archivo inexistente y solicitar uno nuevo. O simplemente deje de informar al usuario que ingresó algo no válido.

5) Lanzar y atrapar 'Exception'es una mala práctica. Pero, en términos más generales, puede lanzar otras excepciones para que la persona que llama pueda decidir cómo lidiar con eso. Por ejemplo, si escribió una biblioteca para manejar la lectura de alguna entrada de archivo y su método pasó a un archivo inexistente, no tiene idea de cómo manejar eso. ¿La persona que llama quiere volver a preguntar o renunciar? Entonces arrojas la Excepción por la cadena de nuevo a la persona que llama.

En muchos casos, unchecked Exceptionocurre porque el programador no verificó las entradas (en el caso de NumberFormatExceptionsu primera pregunta). Es por eso que es opcional atraparlos, porque hay formas más elegantes de evitar generar esas excepciones.

Marcado: propenso a suceder. Comprobado en tiempo de compilación.

Ej. FileOperations

Sin marcar: debido a datos incorrectos. Comprobado en tiempo de ejecución.

P.ej..

String s = "abc";
Object o = s;
Integer i = (Integer) o;

Exception in thread "main" java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer
    at Sample.main(Sample.java:9)

Aquí la excepción se debe a datos incorrectos y de ninguna manera se puede determinar durante el tiempo de compilación.

La JVM verifica las excepciones verificadas en tiempo de compilación y está relacionado con los recursos (archivos / db / stream / socket, etc.). El motivo de la excepción marcada es que, en el momento de la compilación, si los recursos no están disponibles, la aplicación debe definir un comportamiento alternativo para manejar esto en el bloque catch / finally.

Las excepciones no verificadas son errores puramente programáticos, cálculos incorrectos, datos nulos o incluso fallas en la lógica empresarial pueden conducir a excepciones de tiempo de ejecución. Está absolutamente bien manejar / capturar excepciones no verificadas en el código.

Explicación tomada de http://coder2design.com/java-interview-questions/

Mi descripción favorita absoluta de la diferencia entre las excepciones no marcadas y marcadas es proporcionada por el artículo del tutorial de Java Tutorial, " Excepciones no verificadas - la controversia " (perdón por tener todo lo básico en esta publicación, pero, oye, los conceptos básicos son a veces los mejores):

Aquí está la pauta final: 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

El corazón de "qué tipo de excepción lanzar" es semántico (hasta cierto punto) y la cita anterior proporciona una guía excelente (por lo tanto, todavía estoy impresionado por la idea de que C # se deshizo de las excepciones comprobadas, particularmente como Liskov argumenta a favor de su utilidad).

El resto se vuelve lógico: ¿a qué excepciones espera el compilador que responda, explícitamente? De los que espera que el cliente se recupere.

Para responder a la pregunta final (las otras parecen estar completamente respondidas anteriormente), "¿Debo burbujear la excepción exacta o enmascararla usando Exception?"

Supongo que quieres decir algo como esto:

public void myMethod() throws Exception {
    // ... something that throws FileNotFoundException ...
}

No, siempre declare la excepción más precisa posible, o una lista de tales. Las excepciones que declara que su método es capaz de lanzar son parte del contrato entre su método y la persona que llama. Lanzar "FileNotFoundException"significa que es posible que el nombre del archivo no sea válido y que el archivo no se encuentre; la persona que llama tendrá que manejar eso de manera inteligente. Lanzar Exceptionsignifica "Hey, sh * t sucede. Trato". Lo cual es muy pobre API.

En los comentarios sobre el primer artículo hay algunos ejemplos donde "throws Exception" es una declaración válida y razonable, pero ese no es el caso para la mayoría de los normalcódigos " " que escribirás.

Excepciones de tiempo de ejecución : las excepciones de tiempo de ejecución se refieren como excepciones no verificadas. Todas las demás excepciones son excepciones marcadas y no se derivan de java.lang.RuntimeException.

Excepciones marcadas: una excepción marcada debe detectarse en algún lugar de su código. Si invoca un método que arroja una excepción marcada pero no detecta la excepción marcada en alguna parte, su código no se compilará. Es por eso que se llaman excepciones verificadas: el compilador verifica para asegurarse de que se manejan o declaran.

Varios de los métodos en la API de Java arrojan excepciones marcadas, por lo que a menudo escribirá controladores de excepciones para hacer frente a las excepciones generadas por métodos que no escribió.

¿Por qué dejan que la excepción brote? ¿No es mejor manejar el error antes? ¿Por qué burbujear?

Por ejemplo, supongamos que tiene alguna aplicación cliente-servidor y el cliente ha solicitado un recurso que no se pudo encontrar o por algún otro error que podría haber ocurrido en el lado del servidor al procesar la solicitud del usuario, entonces es el deber del servidor para decirle al cliente por qué no pudo obtener lo que solicitó, por lo que para lograr eso en el lado del servidor, el código se escribe para lanzar la excepción usando la palabra clave throw en lugar de tragarlo o manejarlo. si el servidor lo maneja / traga entonces, no habrá ninguna posibilidad de informar al cliente de qué error se ha producido.

Nota: Para dar una descripción clara de qué tipo de error ha ocurrido, podemos crear nuestro propio objeto Exception y lanzarlo al cliente.

Creo que las excepciones marcadas son un buen recordatorio para el desarrollador que usa una biblioteca externa de que las cosas pueden salir mal con el código de esa biblioteca en situaciones excepcionales.

Lea más sobre las excepciones marcadas frente a las no marcadas aquí http://learnjava.today/2015/11/checked-vs-unchecked-exceptions/

Solo quiero agregar algún razonamiento para no usar excepciones marcadas en absoluto. Esta no es una respuesta completa, pero creo que responde parte de su pregunta y complementa muchas otras respuestas.

Siempre que hay excepciones verificadas, hay throws CheckedExceptionuna firma en algún lugar de un método ( CheckedExceptionpodría ser cualquier excepción marcada). Una firma NO arroja una Excepción, lanzar Excepciones es un aspecto de la implementación. Las interfaces, las firmas de métodos, las clases principales, todas estas cosas NO deberían depender de sus implementaciones. El uso de Excepciones marcadas aquí (en realidad el hecho de que tiene que declarar throwsen la firma del método) está vinculando sus interfaces de nivel superior con sus implementaciones de estas interfaces.

Dejame mostrarte un ejemplo.

Tengamos una interfaz agradable y limpia como esta

public interface IFoo {
    public void foo();
}

Ahora podemos escribir muchas implementaciones de métodos foo(), como estos

public class Foo implements IFoo {
    @Override
    public void foo() {
        System.out.println("I don't throw and exception");
    }
}

Class Foo está perfectamente bien. Ahora hagamos un primer intento en la clase Bar

public class Bar implements IFoo {
    @Override
    public void foo() {
        //I'm using InterruptedExcepton because you probably heard about it somewhere. It's a checked exception. Any checked exception will work the same.
        throw new InterruptedException();
    }
}

Esta barra de clase no se compilará. Como InterruptedException es una excepción marcada, debe capturarla (con un método try-catch inside foo ()) o declarar que la está lanzando (agregando throws InterruptedExceptiona la firma del método). Como no quiero capturar esta excepción aquí (quiero que se propague hacia arriba para poder tratarla adecuadamente en otro lugar), modifiquemos la firma.

public class Bar implements IFoo {
    @Override
    public void foo() throws InterruptedException {
        throw new InterruptedException();
    }
}

¡Esta barra de clase tampoco compilará! El método foo () de Bar NO anula el método foo () de IFoo ya que sus firmas son diferentes. Podría eliminar la anotación @Override, pero quiero programar contra la interfaz IFoo like IFoo foo;y luego decidir qué implementación quiero usar, like foo = new Bar();. Si el método foo () de Bar no anula el método foo de IFoo, cuando lo haga foo.foo();no llamará a la implementación de foo () de Bar.

Para public void foo() throws InterruptedExceptionanular los IFoo de Bar, public void foo()DEBO agregar throws InterruptedExceptiona la firma del método de IFoo. Sin embargo, esto causará problemas con mi clase Foo, ya que la firma del método foo () difiere de la firma del método IFoo. Además, si agrego throws InterruptedExceptional método foo () de Foo, obtendría otro error que indica que el método foo () de Foo declara que arroja una InterruptedException, pero nunca arroja una InterruptedException.

Como puede ver (si hice un trabajo decente al explicar esto), el hecho de que estoy lanzando una excepción marcada como InterruptedException me está obligando a vincular mi interfaz IFoo a una de sus implementaciones, lo que a su vez causa estragos en IFoo otras implementaciones!

Esta es una gran razón por la cual las excepciones marcadas son MALAS. En mayúsculas.

Una solución es capturar la excepción marcada, envolverla en una excepción no marcada y lanzar la excepción no marcada.

• Java distingue entre dos categorías de excepciones (marcadas y no marcadas).
• Java impone un requisito de captura o declarado para excepciones marcadas.
• El tipo de una excepción determina si una excepción está marcada o no.
• Todos los tipos de excepción que son directos o indirectos subclassesde clase RuntimeException son excepciones no verificadas.
• Todas las clases que heredan de la clase Exceptionpero no RuntimeExceptionse consideran checked exceptions.
• Las clases que heredan de la clase Error se consideran desmarcadas.
• El compilador comprueba cada llamada al método y la desaceleración para determinar si el método arroja checked exception.
  • Si es así, el compilador asegura que la excepción se detecta o se declara en una cláusula throws.
• Para satisfacer la parte de declarar del requisito de capturar o declarar, el método que genera la excepción debe proporcionar una throwscláusula que contenga el checked-exception.
• Exception Las clases se definen para ser verificadas cuando se consideran lo suficientemente importantes como para atrapar o declarar.

Aquí hay una regla simple que puede ayudarlo a decidir. Está relacionado con la forma en que se utilizan las interfaces en Java.

Tome su clase e imagine diseñar una interfaz para ella de modo que la interfaz describa la funcionalidad de la clase pero ninguna de la implementación subyacente (como debería ser una interfaz). Suponga que tal vez podría implementar la clase de otra manera.

Mire los métodos de la interfaz y considere las excepciones que podrían lanzar:

Si un método puede generar una excepción, independientemente de la implementación subyacente (en otras palabras, solo describe la funcionalidad), entonces probablemente debería ser una excepción comprobada en la interfaz.

Si la implementación subyacente causa una excepción, no debería estar en la interfaz. Por lo tanto, debe ser una excepción no verificada en su clase (ya que las excepciones no verificadas no necesitan aparecer en la firma de la interfaz), o debe envolverla y volver a lanzarla como una excepción marcada que forma parte del método de la interfaz.

Para decidir si debe ajustar y volver a lanzar, debe considerar nuevamente si tiene sentido que un usuario de la interfaz tenga que manejar la condición de excepción de inmediato, o si la excepción es tan general que no hay nada que pueda hacer al respecto y debería propagar hasta la pila. ¿Tiene sentido la excepción envuelta cuando se expresa como funcionalidad de la nueva interfaz que está definiendo o es solo un proveedor de una bolsa de posibles condiciones de error que también podrían ocurrir con otros métodos? Si es lo primero, aún podría ser una excepción marcada, de lo contrario, debería estar desmarcado.

Por lo general, no debe planear "hacer burbujas" excepciones (atrapar y volver a lanzar). La persona que llama debe manejar una excepción (en cuyo caso está marcada) o debe llegar hasta un controlador de alto nivel (en cuyo caso es más fácil si no está marcada).

Solo para señalar que si arroja una excepción marcada en un código y la captura está a pocos niveles arriba, debe declarar la excepción en la firma de cada método entre usted y la captura. Entonces, la encapsulación está rota porque todas las funciones en la ruta de lanzamiento deben conocer los detalles de esa excepción.

En resumen, las excepciones que su módulo o módulos anteriores deben manejar durante el tiempo de ejecución se llaman excepciones verificadas; otros son excepciones no marcadas que son RuntimeExceptiono Error.

En este video, explica las excepciones marcadas y no marcadas en Java:
https://www.youtube.com/watch?v=ue2pOqLaArw

Todas esas son excepciones marcadas. Las excepciones no marcadas son subclases de RuntimeException. La decisión no es cómo manejarlos, es si su código los arroja. Si no desea que el compilador le diga que no ha manejado una excepción, entonces use una excepción no verificada (subclase de RuntimeException). Deben guardarse para situaciones de las que no puede recuperarse, como errores de falta de memoria y similares.

Si a alguien le interesa otra prueba más para que no le gusten las excepciones marcadas, consulte los primeros párrafos de la popular biblioteca JSON:

"Aunque esta es una excepción marcada, rara vez es recuperable. La mayoría de las personas que llaman simplemente deben envolver esta excepción en una excepción no marcada y volver a lanzar:"

Entonces, ¿por qué alguien haría que los desarrolladores sigan comprobando la excepción, si deberíamos "simplemente envolverlo"? jajaja

http://developer.android.com/reference/org/json/JSONException.html

Excepciones marcadas :

• Las excepciones comprobadas por el compilador para la ejecución sin problemas del programa en tiempo de ejecución se denominan Excepción comprobada.

• Estos ocurren en tiempo de compilación.

• Si no se manejan correctamente, darán un error de tiempo de compilación (no excepción).

• Todas las subclases de la clase de excepción, excepto RuntimeException, son excepción comprobada.

  Ejemplo hipotético : suponga que está saliendo de su casa para el examen, pero si verifica si tomó su boleto Hall en casa (tiempo de compilación), entonces no habrá ningún problema en Exam Hall (tiempo de ejecución).

Excepción no marcada :

• Las excepciones que no son verificadas por el compilador se llaman Excepciones no verificadas.

• Estos ocurren en tiempo de ejecución.

• Si estas excepciones no se manejan adecuadamente, no dan error de tiempo de compilación. Pero el programa terminará prematuramente en tiempo de ejecución.

• Todas las subclases de RunTimeException y Error son excepciones no marcadas.

  Ejemplo hipotético : suponga que se encuentra en la sala de examen pero de alguna manera su escuela tuvo un accidente de incendio (es decir, en tiempo de ejecución) donde no puede hacer nada en ese momento, pero se pueden tomar precauciones antes (tiempo de compilación).

Todas las excepciones deben ser marcadas excepciones.

1. Las excepciones no marcadas son gotos sin restricciones. Y los gotos sin restricciones se consideran algo malo.

2. Las excepciones no marcadas rompen la encapsulación. Para procesarlos correctamente, se deben conocer todas las funciones en el árbol de llamadas entre el lanzador y el receptor para evitar errores.

3. Las excepciones son errores en la función que los arroja pero no errores en la función que los procesa. El propósito de las excepciones es dar al programa una segunda oportunidad al diferir la decisión de si es un error o no a otro contexto. Solo en el otro contexto se puede tomar la decisión correcta.