Cuándo elegir excepciones marcadas y no marcadas

De Un Aprendiz de Java :

Cuando se produce una excepción, debe captura y maneja la excepción, o dile al compilador que no puedes manejar al declarar que su método lanza esa excepción, luego el código que utiliza su método tendrá que manejar esa excepción (incluso también puede optar por declarar que lanza la excepción si no puede manejarlo).

El compilador comprobará que hemos hecho una de las dos cosas (catch, or declarar). Así que estos se llaman Comprobados salvedad. Pero Errores y Tiempo de ejecución Las excepciones no son verificadas por compilador (aunque puede elegir para atrapar, o declarar, no es requerir). Por lo tanto, estos dos se llaman Excepciones sin marcar.

Los errores se utilizan para representar aquellos condiciones que ocurren fuera de la aplicación, como el accidente de la sistema. Las excepciones en tiempo de ejecución son por lo general se producen por culpa en el lógica de la aplicación. No puedes hacer cualquier cosa en estos situación. Cuando se produce la excepción de tiempo de ejecución, usted tiene que re-escribir el código del programa. Por lo tanto, estos no son comprobados por el compilador. Estos las excepciones en tiempo de ejecución se descubrirán en desarrollo, y período de prueba. Entonces tenemos que refactorizar nuestro código para eliminar estos errores.

La regla que uso es: ¡nunca use excepciones sin marcar! (o cuando usted no ve ninguna manera alrededor de él)

Hay un caso muy fuerte para lo contrario: Nunca use excepciones comprobadas. Soy reacio a tomar partido en el debate, pero parece haber un amplio consenso de que la introducción de excepciones comprobadas fue una decisión equivocada en retrospectiva. Por favor, no disparen al mensajero y refiéranse a aquellos argumentos .

En cualquier sistema lo suficientemente grande, con muchas capas, las excepciones marcadas son inútiles, ya que, de todos modos, necesita una estrategia de nivel arquitectónico para manejar cómo se manejará la excepción (use una barrera de fallas)

Con excepciones verificadas, su estrategia de manejo de errores es micro-administrada y es insoportable en cualquier sistema grande.

La mayoría de las veces no sabe si un error es "recuperable" porque no sabe en qué capa se encuentra el llamante de su API.

Digamos que yo cree una API StringToInt que convierta la representación de cadena de un entero en un Int. ¿Debo lanzar una excepción marcada si se llama a la API con la cadena" foo"? Es recuperable ? No lo sé porque en su capa el llamante de mi API StringToInt ya puede haber validado la entrada, y si se lanza esta excepción es un error o una corrupción de datos y no es recuperable para esta capa.

En este caso, el llamante de la API no quiere capturar la excepción. Él sólo quiere dejar que la excepción "burbuja". Si elegí una excepción marcada, esta persona que llama tendrá un montón de bloque de captura inútil solo para repensar artificialmente la excepción.

Lo que es recuperable depende la mayor parte del tiempo del llamante de la API, no del escritor de la API. Una API no debe usar excepciones marcadas, ya que solo excepciones sin marcar permite elegir entre capturar o ignorar una excepción.

Tienes razón.

Las excepciones no verificadas se utilizan para permitir que el sistema falle rápidamente, lo cual es algo bueno. Usted debe indicar claramente lo que está esperando su método con el fin de funcionar correctamente. De esta manera, puede validar la entrada solo una vez.

Por ejemplo:

/**
 * @params operation - The operation to execute.
 * @throws IllegalArgumentException if the operation is "exit"
 */
 public final void execute( String operation ) {
     if( "exit".equals(operation)){
          throw new IllegalArgumentException("I told you not to...");
     }
     this.operation = operation; 
     .....  
 }
 private void secretCode(){
      // we perform the operation.
      // at this point the opreation was validated already.
      // so we don't worry that operation is "exit"
      .....  
 }

Solo para poner un ejemplo. El punto es, si el sistema falla rápidamente, entonces usted sabrá dónde y por qué falló. Obtendrás un stacktrace como:

 IllegalArgumentException: I told you not to use "exit" 
 at some.package.AClass.execute(Aclass.java:5)
 at otherPackage.Otherlass.delegateTheWork(OtherClass.java:4569)
 ar ......

Y sabrás lo que pasó. La otra clase en el método " delegateTheWork "(en la línea 4569 ) llamó a su clase con el valor" exit", incluso cuando no debería, etc.

De lo contrario, tendría que rociar validaciones por todo su código y eso es propenso a errores. Además, a veces es difícil rastrear lo que salió mal y puede esperar horas de depuración frustrante

Lo mismo sucede con NullPointerExceptions. Si tiene una clase de 700 líneas con unos 15 métodos, que utiliza 30 atributos y ninguno de ellos puede ser null, en lugar de validar en cada uno de esos métodos la nullabilidad, podría hacer que todos esos atributos sean de solo lectura y validarlos en el método constructor o factory.

 public static MyClass createInstane( Object data1, Object data2 /* etc */ ){ 
      if( data1 == null ){ throw NullPointerException( "data1 cannot be null"); }

  }


  // the rest of the methods don't validate data1 anymore.
  public void method1(){ // don't worry, nothing is null 
      ....
  }
  public void method2(){ // don't worry, nothing is null 
      ....
  }
  public void method3(){ // don't worry, nothing is null 
      ....
  }

Las excepciones verificadas Son útiles cuando el programador ( usted o sus compañeros de trabajo ) hizo todo bien, validó la entrada, ejecutó pruebas y todo el código es perfecto, pero el código se conecta a un servicio web de terceros que puede estar inactivo (o un archivo que estaba utilizando fue eliminado por otro proceso externo, etc ) . El servicio web puede incluso validarse antes de intentar la conexión, pero durante la transferencia de datos algo salió mal.

En ese escenario no hay nada que usted o sus compañeros de trabajo puedan hacer para evitarlo. Pero aún así tienes que hacer algo y no dejar que la aplicación simplemente muera y desaparezca a los ojos del usuario. Usted utiliza una excepción marcada para eso y manejar la excepción, ¿qué puede hacer cuando eso sucede?, la mayoría de las veces, solo para intentar registrar el error, probablemente guardar su trabajo (el trabajo de la aplicación) y presentar un mensaje al usuario. (El sitio blabla está abajo, por favor vuelva a intentarlo más tarde, etc. )

Si la excepción marcada se usa en exceso ( agregando la "excepción throw" en las firmas de todos los métodos ) , entonces su código se volverá muy frágil, porque todos ignorarán esa excepción ( porque es demasiado general ) y la calidad del código se verá seriamente comprometida.

Si utilizas en exceso la excepción no marcada, algo similar ocurrirá. Los usuarios de ese código no sabe si algo puede salir mal y un montón de intentar{...} catch (t lanzable ) aparecerá.

Aquí está mi 'regla general final'.
Uso:

• excepción no marcada dentro del código de mi método para un error debido al llamador (que implica una documentación explícita y completa)
• excepción marcada para un fallo debido al destinatario que necesito hacer explícito a cualquiera que quiera usar mi código

En comparación con la respuesta anterior, esta es una razón clara (sobre la cual uno puede estar de acuerdo o en desacuerdo) para el uso de uno o el otro (o ambos) tipo de excepciones.

Para ambas excepciones, crearé mi propia Excepción sin marcar y marcada para mi aplicación (una buena práctica, como se menciona aquí), excepto para una excepción sin marcar muy común (como NullPointerException)

Así, por ejemplo, el objetivo de esta función particular a continuación es hacer (o obtener si ya existe) un objeto,
significado:

• el contenedor de la el objeto a hacer / obtener DEBE existir (responsabilidad del LLAMANTE
  = > excepción no marcada, Y borrar comentario javadoc para esta función llamada)
• los otros parámetros no pueden ser null
  (elección del codificador para poner eso en la PERSONA que LLAMA: el codificador no comprobará el parámetro null pero el codificador LO DOCUMENTA)
• el resultado NO PUEDE SER NULO
  (responsabilidad y elección del código del llamante, elección que será de gran interés para el llamante
  = > excepción marcada porque todos los llamantes DEBEN tomar una decisión si el objeto no puede ser creado / encontrado,y esa decisión debe ser ejecutada en el momento de la compilación: no pueden usar esta función sin tener que lidiar con esta posibilidad, es decir, con esta excepción marcada).

Ejemplo:

/**
 * Build a folder. <br />
 * Folder located under a Parent Folder (either RootFolder or an existing Folder)
 * @param aFolderName name of folder
 * @param aPVob project vob containing folder (MUST NOT BE NULL)
 * @param aParent parent folder containing folder 
 *        (MUST NOT BE NULL, MUST BE IN THE SAME PVOB than aPvob)
 * @param aComment comment for folder (MUST NOT BE NULL)
 * @return a new folder or an existing one
 * @throws CCException if any problems occurs during folder creation
 * @throws AssertionFailedException if aParent is not in the same PVob
 * @throws NullPointerException if aPVob or aParent or aComment is null
 */
static public Folder makeOrGetFolder(final String aFoldername, final Folder aParent,
    final IPVob aPVob, final Comment aComment) throws CCException {
    Folder aFolderRes = null;
    if (aPVob.equals(aParent.getPVob() == false) { 
       // UNCHECKED EXCEPTION because the caller failed to live up
       // to the documented entry criteria for this function
       Assert.isLegal(false, "parent Folder must be in the same PVob than " + aPVob); }

    final String ctcmd = "mkfolder " + aComment.getCommentOption() + 
        " -in " + getPNameFromRepoObject(aParent) + " " + aPVob.getFullName(aFolderName);

    final Status st = getCleartool().executeCmd(ctcmd);

    if (st.status || StringUtils.strictContains(st.message,"already exists.")) {
        aFolderRes = Folder.getFolder(aFolderName, aPVob);
    }
    else {
        // CHECKED EXCEPTION because the callee failed to respect his contract
        throw new CCException.Error("Unable to make/get folder '" + aFolderName + "'");
    }
    return aFolderRes;
}

No es solo una cuestión de la capacidad de recuperarse de la excepción. Lo que más importa, en mi opinión, es si la persona que llama está interesada en detectar la excepción o no.

Si escribe una biblioteca para ser utilizada en otro lugar, o una capa de nivel inferior en su aplicación, pregúntese si la persona que llama está interesada en detectar (conocer) su excepción. Si no lo es, entonces usa una excepción no controlada, para no sobrecargarlo innecesariamente.

Esta es la filosofía utilizada por muchos marco. Spring e hibernate, en particular, vienen a la mente: convierten excepciones marcadas conocidas en excepciones no marcadas precisamente porque las excepciones marcadas se usan en exceso en Java. Un ejemplo que se me ocurre es la excepción Json de json.org, que es una excepción marcada y es en su mayoría molesto - debe ser sin marcar, pero el desarrollador simplemente no han pensado en ello.

Por cierto, la mayoría de las veces el interés del llamante en la excepción está directamente correlacionado con el capacidad de recuperarse de la excepción, pero ese no es siempre el caso.

Aquí hay una solución muy simple para su dilema Marcado/No marcado.

Regla 1: Piense en una excepción no marcada como una condición comprobable antes de que se ejecute el código. por ejemplo...

x.doSomething(); // the code throws a NullPointerException

Donde x es nulo... possibly el código posiblemente debería tener lo siguiente {

if (x==null)
{
    //do something below to make sure when x.doSomething() is executed, it won’t throw a NullPointerException.
    x = new X();
}
x.doSomething();

Regla 2: Piense en una excepción comprobada como una condición no comprobable que puede ocurrir mientras se ejecuta el código.

Socket s = new Socket(“google.com”, 80);
InputStream in = s.getInputStream();
OutputStream out = s.getOutputStream();

} en el ejemplo anterior, la URL (google.com) puede no estar disponible debido a que el servidor DNS abajo. Incluso en el instante en que el servidor DNS estaba funcionando y resolvió el 'google.com' nombre a una dirección IP, si la conexión se realiza a google.com, en cualquier momento epílogo, la red podría caer. Simplemente no puede probar la red todo el tiempo antes de leer y escribir en las transmisiones.

Hay momentos en los que el código simplemente debe ejecutarse antes de que podamos saber si hay un problema. Obligando a los desarrolladores a escribir su código de tal manera que los obligue a manejar estas situaciones a través de Checked Excepción, tengo que dar la punta de mi sombrero al creador de Java que inventó este concepto.

En general, casi todas las API en Java siguen las 2 reglas anteriores. Si intenta escribir en un archivo, el disco podría llenarse antes de completar la escritura. Es posible que otros procesos que había causado el disco se completa. Simplemente no hay manera de probar esta situación. Para aquellos que interactúan con hardware donde en cualquier momento, el uso del hardware puede fallar, las excepciones verificadas parecen ser un elegante solución a este problema.

Hay un área gris para esto. En el caso de que se necesitan muchas pruebas (una declaración alucinante si con un montón de && y ||), la excepción lanzada será una excepción CheckedException simplemente porque es demasiado de un dolor para hacer bien - simplemente no se puede decir que este problema es un error de programación. Si hay mucho menos de 10 pruebas (por ejemplo, 'if (x == null)'), entonces el error del programador debería ser una excepción no marcada.

Las cosas se ponen interesantes cuando se trata de intérpretes de idiomas. De acuerdo con las reglas anteriores, ¿un Error de Sintaxis debe considerarse una Excepción Marcada o No marcada? Yo argumentaría que si la sintaxis del lenguaje se puede probar antes de que se ejecute, debería ser una excepción sin marcar. Si el lenguaje no se puede probar, de manera similar a cómo se ejecuta el código ensamblador en un ordenador personal, entonces el Error de sintaxis debe ser una Excepción Comprobada.

Las 2 reglas anteriores probablemente eliminarán el 90% de su preocupación sobre cuál elegir. A resuma las reglas, siga este patrón… 1) si el código a ejecutar se puede probar antes de que se ejecute para que se ejecute correctamente y si se produce una Excepción, también conocida como error de programador, la excepción debe ser una excepción no marcada (una subclase de RuntimeException). 2) si el código a ser ejecutado no puede ser probado antes de ser ejecutado para que se ejecute correctamente, la Excepción debe ser una Excepción Comprobada (una subclase de Excepción).

Puede llamarlo una excepción marcada o no marcada; sin embargo, ambos tipos de excepción pueden ser capturados por el programador, por lo que la mejor respuesta es: escriba todas de sus excepciones como sin marcar y documéntelas. De esa manera, el desarrollador que usa tu API puede elegir si quiere detectar esa excepción y hacer algo. Las excepciones verificadas son una completa pérdida de tiempo para todos y hacen que tu código sea una pesadilla impactante. Las pruebas unitarias adecuadas luego traiga cualquier excepción que tenga que atrapar y hacer algo con ella.

Excepción marcada: Si el cliente puede recuperarse de una excepción y desea continuar, utilice excepción marcada.

Excepción no controlada: Si un cliente no puede hacer nada después de la excepción, levante la excepción sin marcar.

Ejemplo: Si se espera que realice una operación aritmética en un método A() y se basa en la salida de A(), debe realizar otra operación. Si la salida es null del método A () que no está esperando durante el tiempo de ejecución, entonces se espera que arroje una excepción de puntero nulo que es una excepción en tiempo de ejecución.

Refiérase aquí

Estoy de acuerdo con la preferencia por excepciones no verificadas como regla, especialmente cuando se diseña una API. La persona que llama siempre puede elegir capturar una excepción documentada y sin marcar. No estás forzando innecesariamente a la persona que llama a hacerlo.

Encuentro útiles las excepciones verificadas en el nivel inferior, como detalle de implementación. A menudo parece un mejor flujo de mecanismo de control que tener que gestionar un error especificado "código de retorno". A veces puede ayudar a ver el impacto de una idea para un nivel bajo cambio de código también... declare una excepción comprobada aguas abajo y vea quién necesitaría ajustar. Este último punto no se aplica si hay muchos genéricos: catch(Exception e) o throws Exception que generalmente no está demasiado bien pensado de todos modos.

Aquí quiero compartir mi opinión que tengo después de muchos años de experiencia en desarrollo:

1. Excepción marcada. Esta es una parte del caso de uso comercial o flujo de llamadas, esta es una parte de la lógica de la aplicación que esperamos o no esperamos. Por ejemplo conexión rechazada, condición no satisfecha, etc. Necesitamos manejarlo y mostrar el mensaje correspondiente al usuario con instrucciones sobre lo que sucedió y qué hacer a continuación (inténtelo de nuevo más tarde, etc.). Normalmente lo llamo excepción de posprocesamiento o " usuario" salvedad.

2. Excepción sin marcar. Esta es una parte de la excepción de programación, algún error en la programación de código de software (error, defecto) y refleja una forma en que los programadores deben usar la API según la documentación. Si un documento de lib / framework externo dice que espera obtener datos en algún rango y no null, porque se lanzará NPE o IllegalArgumentException, el programador debe esperarlo y usar la API correctamente según la documentación. De lo contrario, se lanzará la excepción. Normalmente lo llamo excepción de preprocesamiento o excepción de "validación".

Por público objetivo. Ahora hablemos de público objetivo o grupo de personas las excepciones han sido diseñadas (según mi opinión):

1. Excepción marcada. El público objetivo son los usuarios / clientes.
2. Excepción sin marcar. El público objetivo son los desarrolladores. En otras palabras, las excepciones sin marcar están diseñadas solo para desarrolladores.

Por fase del ciclo de vida de desarrollo de aplicaciones.

1. Comprobado la excepción está diseñada para existir durante todo el ciclo de vida de la producción como mecanismo normal y esperado una aplicación maneja casos excepcionales.
2. La excepción no marcada está diseñada para existir solo durante el ciclo de vida de desarrollo/prueba de la aplicación, todos ellos deben corregirse durante ese tiempo y no deben lanzarse cuando una aplicación ya se está ejecutando en producción.

La razón por la que los frameworks usualmente usan excepciones sin marcar (Spring, por ejemplo) es que el framework no puede determinar la lógica de negocio de su aplicación, esto depende de los desarrolladores para coger a continuación y diseñar la propia lógica.

Las excepciones marcadas son útiles para casos recuperables en los que desea proporcionar información al llamante (es decir, permisos insuficientes, archivo no encontrado, etc.).

Las excepciones no marcadas se usan raramente, si es que se usan, para informar al usuario o programador de errores graves o condiciones inesperadas durante el tiempo de ejecución. No los arroje si está escribiendo código o bibliotecas que serán utilizadas por otros, ya que es posible que no esperen que su software genere excepciones sin verificar desde el compilador no los obliga a ser capturados o declarados.

Cuando sea menos probable que se espere una excepción, y podemos proceder incluso después de capturarla, y no podemos hacer nada para evitar esa excepción, entonces podemos usar la excepción marcada.

Siempre que queramos hacer algo significativo cuando ocurre una excepción en particular y cuando esa excepción es esperada pero no cierta, entonces podemos usar excepción marcada.

Siempre que la excepción navegue en diferentes capas, no necesitamos atraparla en cada capa, en ese caso, podemos usar excepción de tiempo de ejecución o excepción de ajuste como excepción sin marcar.

La excepción en tiempo de ejecución se usa cuando es más probable que ocurra una excepción, no hay forma de ir más allá y nada puede ser recuperable. Así que en este caso podemos tomar precauciones con respecto a esa excepción. EJ: NullPointerException, ArrayOutofBoundsException. Es más probable que ocurran. En este escenario, podemos tomar precauciones al codificar para evitar dicha excepción. De lo contrario tendremos que escribir try catch bloques cada donde.

Se pueden hacer excepciones más generales sin marcar, se marcan menos generales.

Creo que podemos pensar en exepciones de varias preguntas:

¿Por qué ocurre la exepción? ¿Qué podemos hacer cuando sucede

Por error, un bicho. tal como se llama a un método de objeto nulo.

String name = null;
... // some logics
System.out.print(name.length()); // name is still null here

Este tipo de excepción debe fijarse durante el ensayo. De lo contrario, se rompe la producción, y tienes un error muy alto que necesita ser corregido de inmediato. No es necesario comprobar este tipo de excepciones.

Por la entrada del externo, no puede controlar ni confiar en la salida del servicio externo.

String name = ExternalService.getName(); // return null
System.out.print(name.length());    // name is null here

Aquí, es posible que deba verificar si el nombre es null si desea continuar cuando es null, de lo contrario, puede dejarlo solo y se detendrá aquí y le dará a la persona que llama la excepción de tiempo de ejecución. No es necesario comprobar este tipo de excepciones.

Por excepción de tiempo de ejecución de externo, no puede controlar o confiar en el servicio externo.

Aquí, es posible que deba capturar todas las excepciones de ExternalService si desea continuar cuando suceda, de lo contrario, puede dejarlo en paz y se detendrá aquí y le dará a la persona que llama la excepción de tiempo de ejecución.

Por excepción marcada de externo, no puede controlar o confiar en el servicio externo.

Aquí, es posible que necesite capturar todas las excepciones de ExternalService si desea continuar cuando suceda, de lo contrario, puede dejarlo en paz y se detendrá aquí y le dará a la persona que llama la excepción de tiempo de ejecución.

En en este caso, ¿necesitamos saber qué tipo de excepción ocurrió en ExternalService? Depende:

1. Si puede manejar algunos tipos de excepciones, debe capturarlas y procesarlas. Para otros, la burbuja de ellos.

2. Si necesita registrar o responder al usuario de la ejecución específica, puede capturarlos. Para otros, la burbuja de ellos.

Creo que cuando se declara la Excepción de la aplicación debe ser Excepción sin marcar, es decir, subclase de RuntimeException. La razón es que no desordenará el código de la aplicación con try-catch y lanza la declaración en el método. Si su aplicación está utilizando la api de Java que arroja excepciones verificadas que de todos modos deben ser manejadas. Para otros casos, la aplicación puede lanzar una excepción sin marcar. Si el llamante de la aplicación aún necesita manejar la excepción sin marcar, se puede hacer.

Tenemos que distinguir estos dos tipos de excepción en función de si es un error del programador o no.

• Si un error es un error de programador, debe ser una excepción no marcada . Por ejemplo: SQLException/IOException / NullPointerException. Estas excepciones son errores de programación. Deben ser manejados por el programador. Mientras que en JDBC API, SQLException se comprueba Excepción, En Primavera JdbcTemplate es una Excepción No Controlada.Programador no se preocupa sobre SQLException, cuando utilice la primavera.
• Si un error no es un error de programador y la razón viene de un externo, debe ser una Excepción marcada. Por ejemplo: si el archivo se elimina o el permiso de archivo es cambiado por otra persona, Se debe ser recuperado.

FileNotFoundException es un buen ejemplo para entender diferencias sutiles. FileNotFoundException se lanza en caso de que no se encuentre el archivo. Hay dos razones para esta excepción. Si la ruta del archivo es definido por el desarrollador o tomado del usuario final a través de GUI, debería ser una excepción sin marcar. Si el archivo es eliminado por otra persona, debe ser una excepción marcada.

La excepción marcada se puede manejar de dos maneras. Estos están usando try-catch o propagan la excepción. En caso de propagación de la excepción, todos los métodos en la pila de llamadas estarán estrechamente acoplados debido al manejo de excepciones. Es por eso que, tenemos que usar la excepción comprobada con cuidado.

En caso de que desarrolle un sistema de capas de la empresa, usted tiene que elegir la mayoría de excepción sin marcar para lanzar, pero no se olvide de utilizar excepción marcada para el caso de que no puede hacer nada.

La regla que uso es: ¡nunca use excepciones sin marcar! (o cuando usted no ve ninguna manera alrededor de él)

Desde el punto de vista del desarrollador que usa su biblioteca o del usuario final que usa su biblioteca/aplicación, realmente apesta verse enfrentado a una aplicación que se bloquea debido a una excepción no pensada. Y contar con un catch-all tampoco es bueno.

De esta manera el usuario final todavía puede ser presentado con un mensaje de error, en lugar de que la aplicación desaparezca por completo.