Cuándo elegir excepciones marcadas y no marcadas

StackOverflow https://stackoverflow.com/questions/27578

Pregunta

En Java (o cualquier otro lenguaje con excepciones marcadas), al crear su propia clase de excepción, ¿cómo decide si debe marcarla o desmarcarla?

Mi instinto es decir que se requeriría una excepción marcada en los casos en que la persona que llama podría recuperarse de alguna manera productiva, mientras que una excepción no marcada sería más para casos irrecuperables, pero me interesaría conocer las opiniones de los demás.

¿Fue útil?

Solución

Las excepciones marcadas son excelentes, siempre que comprenda cuándo deben usarse.La API principal de Java no sigue estas reglas para SQLException (y a veces para IOException), por lo que son tan terribles.

Excepciones marcadas debe usarse para previsible, pero inevitable errores que son razonable recuperarse de.

Excepciones no marcadas debe usarse para todo lo demás.

Te explicaré esto porque la mayoría de la gente no entiende lo que esto significa.

  1. Predecible pero inevitable:La persona que llama hizo todo lo que estuvo a su alcance para validar los parámetros de entrada, pero alguna condición fuera de su control provocó que la operación fallara.Por ejemplo, intenta leer un archivo pero alguien lo elimina entre el momento en que verifica si existe y el momento en que comienza la operación de lectura.Al declarar una excepción marcada, le está diciendo a la persona que llama que anticipe este error.
  2. Razonable para recuperarse de:No tiene sentido decirles a las personas que llaman que anticipen excepciones de las que no podrán recuperarse.Si un usuario intenta leer un archivo que no existe, la persona que llama puede solicitarle un nuevo nombre de archivo.Por otro lado, si el método falla debido a un error de programación (argumentos de método no válidos o implementación de método defectuosa) no hay nada que la aplicación pueda hacer para solucionar el problema a mitad de la ejecución.Lo mejor que puede hacer es registrar el problema y esperar a que el desarrollador lo solucione más adelante.

A menos que la excepción que estás lanzando cumpla todo De las condiciones anteriores, debe utilizar una excepción no marcada.

Reevaluar en todos los niveles:A veces, el método que detecta la excepción marcada no es el lugar adecuado para manejar el error.En ese caso, considere lo que es razonable para sus propias personas que llaman.Si la excepción es predecible, inevitable y razonable para que se recuperen, entonces usted mismo debe lanzar una excepción marcada.De lo contrario, debe envolver la excepción en una excepción no marcada.Si sigue esta regla, se encontrará convirtiendo excepciones marcadas en excepciones no marcadas y viceversa, dependiendo de la capa en la que se encuentre.

Para excepciones marcadas y no marcadas, utilizar el nivel de abstracción correcto.Por ejemplo, un repositorio de código con dos implementaciones diferentes (base de datos y sistema de archivos) debería evitar exponer detalles específicos de la implementación lanzando SQLException o IOException.En cambio, debería envolver la excepción en una abstracción que abarque todas las implementaciones (p. ej. RepositoryException).

Otros consejos

De Un estudiante de Java:

Cuando se produce una excepción, debe atrapar y manejar la excepción, o decirle al compilador que no puede manejarla declarando que su método arroja esa excepción, entonces el código que usa su método tendrá que manejar esa excepción (incluso IT. También puede optar por declarar que arroja la excepción si no puede manejarlo).

El compilador verificará que hemos hecho una de las dos cosas (atrapar o declarar).Entonces, se llaman excepciones verificadas.Pero los errores y las excepciones de tiempo de ejecución no son verificados por el compilador (aunque puede elegir atrapar o declarar, no es necesario).Entonces, estos dos se llaman excepciones no controladas.

Los errores se utilizan para representar las condiciones que ocurren fuera de la aplicación, como el bloqueo del sistema.Las excepciones de tiempo de ejecución generalmente se producen por fallas en la lógica de la aplicación.No puedes hacer nada en estas situaciones.Cuando se produce una excepción de tiempo de ejecución, debe reescribir su código de programa.Entonces, estos no son verificados por el compilador.Estas excepciones de tiempo de ejecución descubrirán en el período de desarrollo y prueba.Luego tenemos que refactorizar nuestro código para eliminar estos errores.

La regla que uso es:¡Nunca uses excepciones no marcadas!(o cuando no ves ninguna forma de evitarlo)

Hay argumentos muy sólidos a favor de lo contrario:Nunca utilice excepciones marcadas.Soy reacio a tomar partido en el debate, pero parece haber un amplio consenso en que, en retrospectiva, introducir excepciones controladas fue una decisión equivocada.Por favor, no dispare al mensajero y consulte 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 marcadas, su estrategia de manejo de errores está microgestionada y es insoportable en cualquier sistema grande.

La mayoría de las veces no sabes si un error es "recuperable" porque no sabes en qué capa se encuentra la persona que llama a tu API.

Digamos que creo una API StringToInt que convierte la representación de cadena de un número 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 es posible que la persona que llama a mi API StringToInt ya haya validado la entrada, y si se produce esta excepción, es un error o una corrupción de datos y no es recuperable para esta capa.

En este caso, la persona que llama a la API no quiere detectar la excepción.Sólo quiere dejar que la excepción "brogue".Si elijo una excepción marcada, esta persona que llama tendrá muchos bloques de captura inútiles solo para volver a lanzar la excepción artificialmente.

Lo que es recuperable depende la mayor parte del tiempo de quien llama a la API, no de quien escribe la API.Una API no debe utilizar excepciones marcadas, ya que solo las excepciones no marcadas permiten elegir entre detectar o ignorar una excepción.

Estás en lo correcto.

Excepciones no comprobadas se utilizan para permitir que el sistema Fallar rapido Lo que es algo bueno.Debe indicar claramente qué espera su método para que funcione correctamente.De esta manera puedes 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"
      .....  
 }

Sólo por poner un ejemplo.La cuestión es que si el sistema falla rápidamente, entonces sabrá dónde y por qué falló.Obtendrás un seguimiento de pila 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 OtraClase en el método "delegateTheWork" (en la línea 4569) llamó a su clase con el valor de "salida", incluso cuando no debería, etc.

De lo contrario, tendría que esparcir validaciones por todo el código y eso es propenso a errores.Además, a veces es difícil rastrear qué salió mal y es posible que espere horas de depuración frustrante.

Lo mismo sucede con NullPointerExceptions.Si tiene una clase de 700 líneas con unos 15 métodos, que usa 30 atributos y ninguno de ellos puede ser nulo, en lugar de validar en cada uno de esos métodos la nulidad, puede hacer que todos esos atributos sean de solo lectura y validarlos en el constructor o método de fábrica.

 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 
      ....
  }

Excepciones marcadas 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 a un archivo que estaba El uso fue eliminado por otro proceso externo, etc.).Es posible que el servicio web incluso se valide 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 solucionarlo.Pero aún así tienes que hacer algo y no dejar que la aplicación simplemente muera y desaparezca ante los ojos del usuario.Utiliza una excepción marcada para eso y maneja la excepción, ¿qué puede hacer cuando eso sucede? La mayoría de las veces, solo para intentar registrar el error, probablemente guarde su trabajo (el trabajo de la aplicación) y presente un mensaje al usuario. .(El sitio blabla está inactivo, vuelva a intentarlo más tarde, etc.)

Si la excepción marcada se usa en exceso (agregando la "excepción de lanzamiento" en todas las firmas de 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 será seriamente comprometida.

Si usa en exceso una excepción no marcada, sucederá algo similar.Los usuarios de ese código no saben si algo puede salir mal y aparecerán muchos try{...}catch( Throwable t ).

Aquí está mi 'regla general final'.
Yo suelo:

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

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

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

Entonces, por ejemplo, el objetivo de esta función particular a continuación es crear (u obtener si ya existe) un objeto,
significado:

  • el contenedor del objeto a crear/obtener DEBE existir (responsabilidad del LLAMADOR
    => excepción no marcada Y borrar el comentario javadoc para esta función llamada)
  • los demás parámetros no pueden ser nulos
    (elección del codificador para poner eso en la persona que llama:el codificador no verificará el parámetro nulo pero el codificador LO DOCUMENTA)
  • el resultado NO PUEDE SER NULO
    (responsabilidad y elección del código de la persona que llama, elección que será de gran interés para la persona que llama
    => excepción marcada porque cada persona que llama DEBE tomar una decisión si el objeto no se puede crear/encontrar, y esa decisión debe aplicarse en el momento de la compilación:no pueden utilizar esta función sin tener que lidiar con esta posibilidad, es decir, con esta comprobado excepción).

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 se trata sólo 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 usarla 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 es así, utilice una excepción no marcada para no sobrecargarlo innecesariamente.

Esta es la filosofía utilizada por muchos marcos.Spring e Hibernate, en particular, me vienen a la mente: convierten una excepción marcada conocida en una excepción no marcada precisamente porque las excepciones marcadas se usan en exceso en Java.Un ejemplo que se me ocurre es la JSONException de json.org, que es una excepción marcada y es muy molesta: debería estar desmarcada, pero el desarrollador simplemente no lo ha pensado detenidamente.

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

Aquí tienes una solución muy sencilla a tu 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...…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 marcada 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, es posible que la URL (google.com) no esté disponible debido a que el servidor DNS no funciona.Incluso en el instante en que el servidor DNS estaba funcionando y resolvió el nombre "google.com" en una dirección IP, si la conexión se realiza a google.com, en cualquier momento posterior, la red podría caerse.Simplemente no se puede probar la red todo el tiempo antes de leer y escribir en las transmisiones.

Hay ocasiones en las que el código simplemente debe ejecutarse antes de que podamos saber si hay un problema.Al obligar a los desarrolladores a escribir su código de tal manera que los obligue a manejar estas situaciones a través de la excepción marcada, tengo que quitarme el sombrero ante el creador de Java que inventó este concepto.

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

Hay una zona gris en esto.En el caso de que se necesiten muchas pruebas (una declaración if alucinante con muchos && y ||), la excepción lanzada será una CheckedException simplemente porque es demasiado complicado hacerlo bien; simplemente no se puede decir este problema. es un error de programación.Si hay mucho menos de 10 pruebas (p. ej.'if (x == null)'), entonces el error del programador debería ser una excepción UncheckedException.

Las cosas se ponen interesantes cuando se trata de intérpretes de idiomas.De acuerdo con las reglas anteriores, ¿un error de sintaxis debería considerarse una excepción marcada o no marcada?Yo diría que si se puede probar la sintaxis del lenguaje antes de ejecutarlo, debería ser una excepción UncheckedException.Si el lenguaje no se puede probar, de manera similar a cómo se ejecuta el código ensamblador en una computadora personal, entonces el error de sintaxis debería ser una excepción marcada.

Las 2 reglas anteriores probablemente eliminarán el 90% de su preocupación sobre cuál elegir.Para resumir las reglas, siga este patrón ... 1) Si el código que se ejecuta se puede probar antes de que se ejecute para que se ejecute correctamente y si ocurre una excepción, también conocido comoun error del programador, la excepción debe ser una UncheckedException (una subclase de RuntimeException).2) si el código que se va a ejecutar no se puede probar antes de ejecutarlo para que se ejecute correctamente, la excepción debe ser una excepción marcada (una subclase de excepción).

Puede llamarlo excepción marcada o no marcada;sin embargo, ambos El programador puede detectar tipos de excepciones, por lo que la mejor respuesta es:escribir todo de tus excepciones como desenfrenado y documentarlos.De esa manera, el desarrollador que usa su API puede elegir si quiere detectar esa excepción y hacer algo.Las excepciones marcadas son una completa pérdida de tiempo para todos y hacen que su código sea una pesadilla impactante de ver.Las pruebas unitarias adecuadas mostrarán cualquier excepción que deba detectar y hacer algo con ella.

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

Excepción no marcada:Si un cliente no puede hacer nada después de la excepción, genere una excepción no marcada.

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

Referirse aquí

Estoy de acuerdo con la preferencia por excepciones no controladas como regla general, especialmente al diseñar una API.La persona que llama siempre puede optar por detectar una excepción documentada y no comprobada.Simplemente no estás obligando innecesariamente a la persona que llama a hacerlo.

Las excepciones marcadas me parecen útiles en el nivel inferior, como detalle de implementación.A menudo parece un mejor mecanismo de flujo de control que tener que gestionar un "código de retorno" de error específico.A veces también puede ayudar a ver el impacto de una idea para un cambio de código de bajo nivel...declare una excepción marcada en sentido posterior y vea quién necesitaría ajustarse.Este último punto no aplica si hay muchos genéricos: captura (Excepción e) o lanza una excepción que de todos modos no suele estar muy bien pensado.

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

  1. Excepción marcada.Esto es parte del caso de uso empresarial o flujo de llamadas, es parte de la lógica de la aplicación que esperamos o no.Por ejemplo, conexión rechazada, condición no cumplida, 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 excepción de "usuario".

  2. Excepción no comprobada.Esto es parte de una excepción de programación, algún error en la programación del 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 biblioteca/framework externo dice que espera obtener datos en algún rango y que no sean nulos, porque se generará 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 del público objetivo o grupo de personas para las que se han diseñado las excepciones (según mi opinión):

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

Por fase del ciclo de vida del desarrollo de aplicaciones.

  1. La excepción marcada está diseñada para existir durante todo el ciclo de vida de producción como mecanismo normal y esperado en el que 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; todas ellas deben corregirse durante ese tiempo y no deben generarse cuando una aplicación ya se está ejecutando en producción.

La razón por la cual los marcos generalmente usan excepciones no verificadas (Spring, por ejemplo) es que el marco no puede determinar la lógica de negocios de su aplicación, esto depende de los desarrolladores detectarlo y diseñar su propia lógica.

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

Las excepciones no comprobadas rara vez se utilizan, o se utilizan, para informar al usuario o programador sobre 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 arroje excepciones no comprobadas, ya que el compilador no obliga a detectarlas ni declararlas.

Siempre que sea menos probable que se espere una excepción y podamos continuar incluso después de detectarla y no podamos hacer nada para evitarla, entonces podemos usar la excepción marcada.

Siempre que queramos hacer algo significativo cuando ocurre una excepción particular y cuando esa excepción se espera pero no es segura, entonces podemos usar la excepción marcada.

Siempre que una excepción navega en diferentes capas, no es necesario detectarla en cada capa; en ese caso, podemos usar una excepción de tiempo de ejecución o ajustar la excepción como una excepción no marcada.

La excepción de tiempo de ejecución se utiliza cuando es más probable que ocurra una excepción, no hay forma de ir más allá y no se puede recuperar nada.Entonces en este caso podemos tomar precauciones con respecto a esa excepción.EX:NUllPointerException, ArrayOutofBoundsException.Es más probable que esto suceda.En este escenario, podemos tomar precauciones mientras codificamos para evitar dicha excepción.De lo contrario, tendremos que escribir bloques try catch en todas partes.

Se pueden hacer excepciones más generales sin marcar, las menos generales están marcadas.

Creo que podemos pensar en excepciones a varias preguntas:

¿Por qué ocurre la excepción?¿Qué podemos hacer cuando suceda?

por error, un error. 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 solucionarse durante la prueba.De lo contrario, se interrumpe la producción y se produce un error muy elevado que debe solucionarse de inmediato.No es necesario comprobar este tipo de excepciones.

por entrada externa, no se puede controlar ni confiar en el resultado de un 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 nulo si desea continuar cuando sea nulo; 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.No es necesario comprobar este tipo de excepciones.

por excepción de tiempo de ejecución externa, no se puede controlar ni confiar en el servicio externo.

Aquí, es posible que necesite detectar 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 desde externo, no se puede controlar ni confiar en el servicio externo.

Aquí, es posible que necesite detectar 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 este caso, ¿necesitamos saber qué tipo de excepción ocurrió en ExternalService? Eso depende:

  1. Si puede manejar algunos tipos de excepciones, debe detectarlas y procesarlas.Para otros, burbujearlos.

  2. Si necesita registrar o responder al usuario la excepción específica, puede capturarlos.Para otros, burbujearlos.

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

  • Si un error es un error del 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 la API JDBC, SQLException se verifica la excepción, en Spring JDBCTemplate es una excepción sin control. Programmer no se preocupa por SQLException, cuando se usa Spring.
  • Si un error no es un error del programador y el motivo proviene de algo externo, debe ser una excepción marcada. Por ejemplo:Si se elimina el archivo o otra persona cambia el permiso del archivo, debe recuperarse.

FileNotFoundException es un buen ejemplo para comprender 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 la define el desarrollador o la toma del usuario final a través de la GUI, debería ser una excepción no marcada.Si otra persona elimina el archivo, debería ser una excepción marcada.

La excepción marcada se puede manejar de dos maneras.Estos utilizan try-catch o propagan la excepción.En caso de propagación de excepción, todos los métodos en la pila de llamadas serán estrechamente acoplado debido al manejo de excepciones.Por eso debemos utilizar la excepción marcada con cuidado.

En caso de que desarrolle un sistema empresarial en capas, debe elegir la excepción que no está marcada para lanzar, pero no olvide usar la excepción marcada en el caso de que no pueda hacer nada.

Creo que al declarar una excepción de aplicación debería ser una excepción no marcada, es decir, una subclase de RuntimeException.La razón es que no saturará el código de la aplicación con try-catch y declaraciones de lanzamiento en el método.Si su aplicación utiliza Java Api, que arroja excepciones marcadas que de todos modos deben manejarse.En otros casos, la aplicación puede generar una excepción no comprobada.Si la persona que llama a la aplicación aún necesita manejar la excepción no marcada, puede hacerlo.

La regla que uso es:¡Nunca uses excepciones no marcadas!(o cuando no ves ninguna forma de evitarlo)

Desde el punto de vista del desarrollador que usa su biblioteca o del usuario final que usa su biblioteca/aplicación, realmente apesta enfrentarse a una aplicación que falla debido a una excepción no detectada.Y contar con un comodín tampoco sirve.

De esta manera, aún se puede presentar un mensaje de error al usuario final, en lugar de que la aplicación desaparezca por completo.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top