CodeGym /Blog Java /Random-ES /Excepciones: marcado, no marcado y personalizado
Autor
Volodymyr Portianko
Java Engineer at Playtika

Excepciones: marcado, no marcado y personalizado

Publicado en el grupo Random-ES
¡Hola! En la última lección, nos familiarizamos con las excepciones en el lenguaje Java y vimos ejemplos de cómo trabajar con ellas. Hoy analizaremos más a fondo la estructura de las excepciones y aprenderemos a escribir nuestras propias excepciones :)

Tipos de excepciones

Como dijimos anteriormente, hay muchas excepciones en Java, ¡casi 400! Pero todos están divididos en grupos, por lo que es bastante fácil recordarlos. Así es como se ve: Excepciones: marcado, no marcado y personalizado - 2 Todas las excepciones tienen un ancestro común en la Throwableclase. De él se derivan dos grandes grupos: excepciones ( Exception ) y errores ( Error ). Error : representa un error de tiempo de ejecución crítico relacionado con el funcionamiento de la máquina virtual Java. En la mayoría de los casos, no es necesario controlar el error, ya que indica algunas fallas graves en el código. Los más famosos son StackOverflowError (esto ocurre, por ejemplo, cuando un método se llama a sí mismo sin cesar) y OutOfMemoryError .(esto ocurre cuando no hay suficiente memoria para crear nuevos objetos). Como puede ver, en estas situaciones, por lo general no hay absolutamente nada que manejar en tiempo de ejecución: el código simplemente se escribe incorrectamente y necesita ser reelaborado. Excepción : esto representa, bueno, una excepción: una situación excepcional no planificada que ocurre mientras se ejecuta el programa. No son tan serios como el Error, pero aun así requieren nuestra atención. Todas las excepciones se dividen en 2 tipos: marcadas y no marcadas . Excepciones: marcado, no marcado y personalizado - 3 Todas las excepciones marcadas se derivan de la Exceptionclase. ¿Qué significa "marcado"? Aludimos a esto en la última lección: "El compilador de Java, por lo tanto, conoce las excepciones más comunes y las situaciones en las que pueden ocurrir". Por ejemplo, sabe que si el código lee datos de un archivo, el archivo fácilmente podría no existir. Y hay muchas de esas situaciones (que se pueden inferir). En consecuencia, el compilador verifica nuestro código por adelantado para detectar la presencia de estas posibles excepciones. Si los encuentra, no compilará el código hasta que los hayamos manejado o los hayamos vuelto a lanzar. El segundo tipo de excepción está "desmarcado". Se derivan de la RuntimeExceptionclase. ¿En qué se diferencian de las excepciones comprobadas? Parece que también hay muchas clases diferentes derivadas deRuntimeException(que describen excepciones de tiempo de ejecución). La diferencia es que el compilador no anticipa estos errores. Parece estar diciendo: "Cuando se escribió el código, no encontré nada sospechoso, pero algo salió mal mientras se ejecutaba. Aparentemente, hay errores en el código". Y de hecho esto es cierto. Las excepciones no comprobadas suelen ser el resultado de errores del programador. Y el compilador, obviamente, no puede prever todas las posibles malas situaciones que la gente podría crear con sus propias manos. :) Por lo tanto, no verifica si tales excepciones se manejan en nuestro código. Ya ha encontrado varias excepciones no verificadas:
  • Se produce una excepción aritmética al dividir por cero
  • Se produce una ArrayIndexOutOfBoundsException cuando intenta acceder a una posición fuera de la matriz.
Por supuesto, puede imaginar que los creadores de Java podrían haber introducido el manejo de excepciones obligatorio, pero en este caso el código sería demasiado complicado. Para cualquier operación de división, ¿tendría que escribir un try-catchbloque para verificar si dividió accidentalmente por cero? Cada vez que accediera a una matriz, tendría que escribir un try-catchbloque para verificar si su índice estaba fuera de los límites. Todo sería código espagueti y sería completamente ilegible. Tiene sentido que se abandonara esta idea. Como resultado, las excepciones no verificadas no necesitan manejarse en try-catchbloques o volver a lanzarse (aunque esto es técnicamente posible, como con Error).

Cómo lanzar tu propia excepción

Por supuesto, los creadores de Java no pueden prever todas las situaciones excepcionales que pueden surgir en los programas. Hay demasiados programas en el mundo, y son demasiado diversos. Pero esto no es motivo de preocupación, ya que puede crear su propia excepción, si es necesario. Esta muy fácil de hacer. Todo lo que tienes que hacer es crear tu propia clase. Debe asegurarse de que su nombre termine con "Excepción". El compilador no requiere esto, pero otros programadores que lean su código entenderán inmediatamente que es una clase de excepción. Además, indique que la clase se hereda de la Exceptionclase (el compilador lo requiere). Por ejemplo, supongamos que tenemos una Dogclase. Podemos pasear al perro usando elwalk()método. Pero antes de hacerlo, debemos comprobar si nuestra mascota lleva collar, correa y bozal. Si falta algo de este equipo, lanzamos nuestra propia excepción: DogIsNotReadyException . Su código se ve así:

public class DogIsNotReadyException extends Exception {

   public DogIsNotReadyException(String message) {
       super(message);
   }
}
Para indicar que la clase es una excepción, debe escribir " extiende la excepción " después del nombre de la clase (esto significa que "la clase se deriva de la clase de excepción"). En el constructor, simplemente llamamos al Exceptionconstructor de la clase con el mensaje String (si ocurre la excepción, mostraremos el mensaje, una descripción del error, al usuario). Así es como se ve esto en nuestro código de clase:

public class Dog {

   String name;
   boolean isCollarPutOn;
   boolean isLeashPutOn;
   boolean isMuzzlePutOn;


   public Dog(String name) {
       this.name = name;
   }

   public static void main(String[] args) {

   }

   public void putCollar() {

       System.out.println("The collar is on!");
       this.isCollarPutOn = true;
   }

   public void putLeash() {

       System.out.println("The leash is on!");
       this.isLeashPutOn = true;
   }

   public void putMuzzle() {
       System.out.println("The muzzle is on!");
       this.isMuzzlePutOn = true;
   }

   public void walk() throws DogIsNotReadyException {

   System.out.println("We're getting ready for a walk!");
   if (isCollarPutOn && isLeashPutOn && isMuzzlePutOn) {
       System.out.println("Hooray, let's go for a walk! " + name + " is very happy!");
   } else {
       throw new DogIsNotReadyException(name + " is not ready for a walk! Check the gear!");
   }
 }

}
Ahora nuestro walk()método lanza una excepción DogIsNotReadyException . Esto se hace con la palabra clave throw. Como dijimos antes, una excepción es un objeto. Entonces, cuando ocurre una excepción (al perro le falta algo) en nuestro método, creamos un nuevo DogIsNotReadyExceptionobjeto y lo lanzamos usando la palabra clave throw. Agregamos " throws DogIsNotReadyException " a la declaración del método. En otras palabras, ahora el compilador es consciente de que llamar al walk()método podría convertirse en una situación excepcional. En consecuencia, esta excepción debe manejarse si llamamos a este método en algún lugar de nuestro programa. Intentemos hacer esto en el main()método:

public static void main(String[] args) {
  
   Dog dog = new Dog("Buddy");
   dog.putCollar();
   dog.putMuzzle();
   dog.walk();// Unhandled exception: DogIsNotReadyException
}
Esto no compilará. ¡La excepción no se maneja! Envolvemos nuestro código en un try-catchbloque para manejar la excepción:

public static void main(String[] args) {

   Dog dog = new Dog("Buddy");
   dog.putCollar();
   dog.putMuzzle();
   try {
       dog.walk();
   } catch (DogIsNotReadyException e) {
       System.out.println(e.getMessage());
       System.out.println("Checking the gear! Is the collar on? " + dog.isCollarPutOn + "\r\n Is the leash on? "
       + dog.isLeashPutOn + "\r\n Is the muzzle on? " + dog.isMuzzlePutOn);
   }
}
Ahora veamos la salida de la consola: ¡ El collar está encendido! ¡El bozal está encendido! ¡Nos estamos preparando para un paseo! ¡Buddy no está listo para dar un paseo! ¡Compruebe el equipo! ¡Comprobando el equipo! ¿Está puesto el collar? cierto ¿Está puesta la correa? false ¿Está puesto el bozal? true ¡ Mira cuánto más informativo fue el resultado de la consola! Vemos cada paso dado en el programa; vemos dónde ocurrió el error, y también podemos ver de inmediato exactamente lo que le falta a nuestro perro. :) Y así es como creas tus propias excepciones. Como puede ver, no hay nada complicado al respecto. Y aunque los creadores de Java no se molestaron en incluir en el lenguaje una excepción especial para perros mal equipados, solucionamos su descuido. :)
Comentarios
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION