java - color - jpanel

Java: explicación de excepción marcada vs no comprobada

Question

He leído varias publicaciones en StackOverFlow sobre excepciones comprobadas y no comprobadas. Sinceramente, todavía no estoy seguro de cómo usarlos correctamente.

Joshua Bloch en " Java efectiva " dijo que

Utilice excepciones comprobadas para condiciones recuperables y excepciones de tiempo de ejecución para errores de programación (Artículo 58 en la 2ª edición)

A ver si entiendo esto correctamente.

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

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. ¿Lo anterior se considera una excepción marcada?

2. ¿Es RuntimeException una excepción sin marcar?

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

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 también ser una excepción comprobada? ¿Puedo intentar recuperar la situación así? ¿Puedo? (Nota: mi tercera pregunta está dentro de la catch arriba)

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 brille la excepción? ¿No es mejor manejar el error antes? ¿Por qué burbuja?

EDITAR: ¿Debo aumentar la excepción exacta o enmascararla utilizando Exception?

A continuacion estan 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

Answer 1

1. ¿Lo anterior se considera una excepción marcada? No El hecho de que esté manejando una excepción no la convierte en una excepción comprobada si se trata de una excepción RuntimeException.

2. ¿Es RuntimeException una excepción sin marcar? Sí

Las excepciones marcadas son subclases de java.lang.Exception. Las excepciones no comprobadas son subclases de java.lang.RuntimeException.

Las llamadas que emiten excepciones marcadas deben incluirse en un bloque try {} o manejarse en un nivel superior en la persona que llama al método. En ese caso, el método actual debe declarar que lanza dichas excepciones para que las personas que llaman puedan hacer los arreglos apropiados para manejar la excepción.

Espero que esto ayude.

P: ¿Debo aumentar la excepción exacta o enmascararla utilizando Exception?

R: Sí, esta es una muy buena pregunta y una importante consideración de diseño. La excepción de clase es una clase de excepción muy general y puede usarse para envolver excepciones internas de bajo nivel. Sería mejor crear una excepción personalizada y envolverla dentro. Pero, y uno grande: nunca se oculta en la causa original subyacente. Por ejemplo, Dont ever hagas 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!.
}

Comerse la causa 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 se les da acceso a todos los registros de aplicaciones y 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 quien llama. Así que tome una nota firme: Always pass on the actual exception devuelva la Always pass on the actual exception ya sea envuelta o no en alguna excepción específica de la aplicación.

En la prueba RuntimeExceptions

Las excepciones RuntimeExceptions como una regla general no deben ser intentadas. En general, señalan un error de programación y deben dejarse solos. En su lugar, el programador debe verificar la condición de error antes de invocar algún código que podría resultar en una excepción RuntimeException. Por ejemplo:

try {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome 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 su lugar, debería haberse realizado una comprobación nula 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 ocasiones en que dicha comprobación de errores es costosa, como el formato de número, 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 antes de 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. Así que es mejor simplemente eliminar el try-catch.

Por lo tanto, NullPointerException y NumberFormatException son RuntimeExceptions, la captura de una NullPointerException debe ser reemplazada por una comprobación nula elegante, mientras que recomiendo capturar una NumberFormatException explícitamente para evitar la posible introducción de código propenso a errores.

Answer 2

1) No, una excepción NumberFormatException es una excepción sin marcar. A pesar de que lo atrapó (no está obligado a hacerlo), está desactivado. Esto se debe a que es una subclase de IllegalArgumentException que es una subclase de RuntimeException.

2) RuntimeException es la raíz de todas las excepciones sin marcar. Cada subclase de RuntimeException está desactivada. Todas las demás excepciones y Throwables están marcados, excepto los errores (que se incluyen en Throwable).

3/4) Podría alertar al usuario de que eligió un archivo inexistente y pedir uno nuevo. O simplemente deje de informarle al usuario que ingresó algo no válido.

5) Lanzar y atrapar ''Excepción'' es una mala práctica. Pero de manera más general, 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ó un archivo inexistente, no tiene idea de cómo manejar eso. ¿La persona que llama quiere preguntar de nuevo o renunciar? Así que le devuelves la excepción a la persona que llama.

En muchos casos, se produce una excepción sin marcar porque el programador no verificó las entradas (en el caso de NumberFormatException en su primera pregunta). Por eso es opcional atraparlos, porque hay formas más elegantes de evitar generar esas excepciones.

Answer 3

1. Si no está seguro 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 todas las excepciones que lo amplíen.

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

4. La excepción FileNotFoundException ya es una excepción comprobada.

5. Si se espera que el método llame a someMethod para capturar la excepción, este último puede 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 propio 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 marcadas no detectadas que se pueden lanzar dentro de su alcance? Cualquier excepción que pueda ser lanzada por 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 un método puede lanzar para que puedan 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 el 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 lanzar, ¿por qué no especificar también las excepciones en tiempo de ejecución?" Las excepciones en tiempo de ejecución representan problemas que son el resultado de un problema de programación y, como tal, no se puede esperar que el código de cliente API se recupere de ellos o los maneje de alguna manera. Tales problemas incluyen excepciones aritméticas, como la división por cero; excepciones de puntero, como intentar acceder a un objeto a través de una referencia nula; y las 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 de lanzamientos forman parte del contrato entre el implementador y el usuario del método o constructor .

El resultado final es que puede capturar cualquier RuntimeException , pero no está obligado a hacerlo y, de hecho, no se requiere que la implementación mantenga las mismas excepciones no verificadas, ya que no forman parte del contrato.

Answer 4

Comprobado - propenso a suceder. Comprobado en tiempo de compilación.

Ej. .. FileOperations

Sin comprobar - 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 erróneos y de ninguna manera se puede determinar durante el tiempo de compilación.

Answer 5

La JVM verifica las excepciones verificadas en el momento de la compilación y está relacionada con los recursos (archivos / db / stream / socket, etc.). El motivo de la excepción comprobada 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 puramente errores programáticos, cálculos erróneos, datos nulos o incluso fallas en la lógica de negocios que pueden llevar a excepciones en tiempo de ejecución. Está absolutamente bien para manejar / capturar excepciones sin marcar en el código.

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

Answer 6

Muchas personas dicen que las excepciones marcadas (es decir, las que debe capturar o volver a realizar explícitamente) no deben usarse en absoluto. Fueron eliminados 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 sin marcar)

Sin embargo, creo que las excepciones marcadas son útiles, se usan cuando se quiere forzar 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 vista extendida sobre el tema .

En cuanto a las preguntas particulares:

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

2. ¿Es RuntimeException una excepción sin marcar?
   Sí exactamente.

3. ¿Qué debo hacer aquí?
   Depende de dónde esté este código y de lo que quiera que suceda. Si está en la capa UI, cógela y muestra una advertencia; si está en la capa de servicio, no lo atrape en absoluto, déjelo burbujear. Simplemente no trague la excepción. Si se produce una excepción en la mayoría de los casos, debe elegir uno de estos:

   • iniciar sesión y volver
   • volver a lanzarlo (declararlo para ser lanzado 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 comprobada? ¿Puedo intentar recuperar la situación así? ¿Puedo?
   Podría haber sido. Pero nada te impide ver la excepción sin marcar también

5. ¿Por qué la gente agrega Exception clase en la cláusula de lanzamientos?
   Más a menudo porque las personas son perezosas a la hora de considerar qué atrapar y qué retomar. Lanzar Exception es una mala práctica y debe evitarse.

Lamentablemente, no hay una sola regla que le permita determinar cuándo capturar, cuándo volver a lanzar, cuándo usar las opciones marcadas y cuándo usar las excepciones no verificadas. Estoy de acuerdo en que esto causa mucha confusión y muchos códigos malos. El principio general lo establece Bloch (usted citó una parte de él). Y el principio general es volver a lanzar una excepción a la capa donde puede manejarlo.

Answer 7

Para responder a la pregunta final (los demás parecen estar completamente respondidos más arriba), "¿Debo aumentar la excepción exacta o enmascararla utilizando la excepción?"

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 usted declara que su método es capaz de lanzar forman 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 no se encuentre el archivo; la persona que llama tendrá que manejar eso de manera inteligente. Lanzar "Excepción" significa "Oye, sh * t sucede. Repartir". Que es una API muy pobre.

En los comentarios sobre el primer artículo hay algunos ejemplos en los que "arroja Excepciones" es una declaración válida y razonable, pero ese no es el caso de la mayoría del código "normal" que escribirá.

Answer 8

Si algo es una "excepción comprobada" no tiene nada que ver con si lo atrapa o lo que hace en el bloque catch. Es una propiedad de las clases de excepción. Cualquier cosa que sea una subclase de Exception excepto RuntimeException y sus subclases, es una excepción comprobada.

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

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

Porque ese es todo el punto de las excepciones. Sin esta posibilidad, no necesitarías excepciones. Le permiten manejar los errores en el nivel que elija, en lugar de obligarlo a lidiar con ellos en métodos de bajo nivel donde se producen originalmente.

Answer 9

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

Cuando hay excepciones verificadas involucradas, hay una throws CheckedException en algún lugar en una firma de método ( CheckedException podría ser cualquier excepción marcada). Una firma NO lanza una excepción, lanzar excepciones es un aspecto de la implementación. Las interfaces, las firmas de métodos, las clases primarias, todas estas cosas NO deben depender de sus implementaciones. El uso de las excepciones verificadas aquí (en realidad, el hecho de que tenga que declarar los throws en 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 del método foo() , como estas

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

La clase Foo está perfectamente bien. Ahora hagamos un primer intento en 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 clase Bar no compilará. Como InterruptedException es una excepción marcada, debe capturarla (con un try-catch dentro del método foo ()) o declarar que la está lanzando (agregando la throws InterruptedException a 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 no compilará tampoco! 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 como IFoo foo; y luego decidir qué implementación quiero usar, como foo = new Bar(); . Si el método foo () de Bar no anula el método foo de IFoo, cuando lo hago foo.foo(); no llamará a la implementación de foo () de Bar.

Para hacer que el public void foo() throws InterruptedException de Bar public void foo() throws InterruptedException anule el public void foo() de IFoo public void foo() DEBO agregar throws InterruptedException a la firma del método de IFoo. Esto, sin embargo, causará problemas con mi clase Foo, ya que la firma del método foo () difiere de la firma del método de IFoo. Además, si agrego throws InterruptedException al método foo () de Foo, obtendría otro error que indica que el método foo () de Foo declara que lanza un objeto InterruptedException sin embargo, nunca lanza un objeto InterruptedException.

Como puede ver (si hice un trabajo decente al explicar esto), el hecho de que esté lanzando una excepción comprobada como InterruptedException me obliga a vincular mi interfaz IFoo con una de sus implementaciones, lo que a su vez causa estragos en la Otras implementaciones!

Esta es una de las grandes razones por las que las excepciones marcadas son MALAS. En mayúsculas.

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

Answer 10

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

Por ejemplo, digamos que tiene alguna aplicación cliente-servidor y el cliente ha realizado una solicitud de algún recurso que no se pudo encontrar o por algún otro error podría haber ocurrido en el lado del servidor al procesar la solicitud del usuario, entonces es su deber del servidor para decirle al cliente por qué no pudo obtener lo que solicitó, por lo que para lograrlo en el servidor, se escribe el código para lanzar la excepción usando la palabra clave throw en lugar de tragarlo o manejarlo. De esta forma, no habrá posibilidad de intimidar al cliente sobre el error que se ha producido.

Nota: Para proporcionar una descripción clara de qué tipo de error se ha producido, podemos crear nuestro propio objeto de Excepción y enviarlo al cliente.

Answer 11

Excepciones comprobadas :

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

• Estos ocurren en tiempo de compilación.

• Si estos 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 la excepción RuntimeException, se revisan como excepción.

  Ejemplo hipotético : suponga que va a salir de su casa para el examen, pero si comprueba si se llevó el ticket de entrada a su casa (tiempo de compilación), no habrá ningún problema en la sala de exámenes (tiempo de ejecución).

Excepción no marcada :

• Las excepciones que no son verificadas por el compilador se denominan 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 el tiempo de ejecución.

• Todas las subclases de RunTimeException y Error son excepciones sin marcar.

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

Answer 12

Excepciones en tiempo de ejecución Las excepciones en tiempo de ejecución se conocen como excepciones sin marcar. Todas las demás excepciones son excepciones comprobadas y no se derivan de java.lang.RuntimeException.

Excepciones marcadas Una excepción marcada debe capturarse en algún lugar de su código. Si invocas un método que lanza una excepción marcada pero no atrapas la excepción marcada en algún lugar, tu código no se compilará. Es por eso que se llaman excepciones comprobadas: el compilador verifica para asegurarse de que son manejados o declarados.

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

Answer 13

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

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

Answer 14

Si alguien se preocupa por otra prueba que no le guste las excepciones marcadas, vea 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 deberían simplemente envolver esta excepción en una excepción no verificada y volver a realizarla:"

Entonces, ¿por qué alguien haría que los desarrolladores siguieran verificando la excepción, si en lugar de eso simplemente "lo envolviéramos"? jajaja

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

Answer 15

Todas las excepciones deben ser comprobadas excepciones.

1. Las excepciones no controladas son gotos no restringidos. Y los gotos no restringidos son considerados algo malo.

2. Excepciones no verificadas rompen la encapsulación. Para procesarlos correctamente, todas las funciones en el árbol de llamadas entre el lanzador y el receptor deben ser conocidas para evitar errores.

3. Las excepciones son errores en la función que los lanza, 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.

Answer 16

Aquí hay una regla simple que puede ayudarte a decidir. Está relacionado con cómo se usan las interfaces en Java.

Tome su clase e imagine el diseño de una interfaz para tal que la interfaz describa la funcionalidad de la clase pero ninguna de las implementaciones subyacentes (como debería ser una interfaz) Imagina que podrías 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 lanzar una excepción, independientemente de la implementación subyacente (en otras palabras, solo describe la funcionalidad), entonces probablemente debería ser una excepción marcada en la interfaz.

Si una excepción es causada por la implementación subyacente, 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 tienen que aparecer en la firma de la interfaz), o debe ajustarlo y volver a emitir como una excepción marcada que forma parte del método de la interfaz.

Para decidir si debe ajustar y volver a generar, debe considerar nuevamente si tiene sentido para un usuario de la interfaz tener 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 por la pila. ¿Tiene sentido la excepción envuelta cuando se expresa como la 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 el primero, aún podría ser una excepción marcada, de lo contrario debería estar desactivada.

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

Answer 17

En resumen, las excepciones que su módulo o módulos anteriores deben manejar durante el tiempo de ejecución se denominan excepciones de verificación, otras son excepciones sin verificar que son RuntimeExceptiono Error. En este video, explica las excepciones marcadas y no marcadas en java. https://www.youtube.com/watch?v=ue2pOqLaArw

Answer 18

Mi descripción favorita absoluta de la diferencia entre las excepciones no verificadas y las comprobadas se encuentra en el artículo del Tutorial de Java, " Excepciones no verificadas : la controversia " (lamento tener todas las notas elementales en esta publicación, pero, bueno, a veces lo básico es lo mejor):

Esta es la línea de fondo: si se puede esperar que un cliente se recupere de una excepción, conviértalo en una excepción comprobada. Si un cliente no puede hacer nada para recuperarse de la excepción, conviértalo en una excepción sin marcar

El corazón de "qué tipo de excepción lanzar" es semántico (hasta cierto punto) y la cita anterior proporciona una excelente guía (por lo tanto, todavía me sorprende la idea de que C # se haya librado de las excepciones comprobadas, especialmente cuando Liskov defiende su utilidad).

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

Answer 19

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

Answer 20

Todos esos son excepciones verificadas. Las excepciones no verificadas son subclases de RuntimeException. La decisión no es cómo manejarlos, es si su código los lanza. Si no quiere 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 pueda recuperarse, como errores de memoria y similares.

Answer 21

• Java distingue dos categorías de excepciones (marcadas y sin marcar)
• Java aplica un retén o un requisito declarado para las excepciones comprobadas
• El tipo de una excepción determina si una excepción está marcada o no.
• Todos los tipos de excepción que son subclases directas o indirectas de la clase RuntimeException son excepciones sin marcar.
• Todas las clases que heredan de la clase Exception pero no RuntimeException se consideran excepciones comprobadas.
• Las clases que heredan de la clase Error se consideran sin marcar.
• El compilador verifica cada llamada de método y desaceleración para determinar si el método arroja una excepción verificada.
  • Si es así, el compilador garantiza que la excepción se capture o se declare en una cláusula de lanzamientos.
• Para satisfacer la parte declarada del requisito de captura o declaración, el método que genera la excepción debe proporcionar una cláusula de lanzamientos que contenga la excepción marcada.
• Las clases de excepción se definen para verificarlas cuando se consideran lo suficientemente importantes como para capturar o declarar.