Bienvenidos.
Vamos a ver una introducción al manejo de errores excepciones en Java.
Bien, existe una regla muy importante en el mundo de la programación en cualquier lenguaje, que lo
más probable que nuestras aplicaciones ocurran errores.
Y eso es así.
Bueno, pero qué sucede realmente?
Después de que pasa algo?
Ocurre un error?
Cómo se maneja el error?
Quién lo maneja?
Se puede recuperar o no nuestra aplicación?
Son varias preguntas que iremos respondiendo en el transcurso de esta sección.
Bueno, ya va.
Utiliza excepciones que básicamente es un tipo especial de objetos que nos proporciona una forma simple
y también desacoplar ya el manejo de error y desacoplar.
Me refiero al código principal de nuestro programa desacoplar, por ejemplo, de la lógica negocio de
nuestro código principal.
Todo lo que sea error.
Y eso le lleva a otro componente, a otra clase.
Y de ahí podemos manejar todo los errores.
Bien, entonces en esta sección aprenderemos que es una acepción.
Cómo se puede lanzar?
Cómo se puede capturar y manejar esto?
Errores?
Qué hacer con una acepción?
Una vez que capturada.
Y también cómo hacer un mejor uso de excepciones un poco más personalizadas que heredan de algunas clases.
Decepción que nos proporciona el lenguaje Java.
Bien.
Pero la gran pregunta qué es lo que es una acepción?
Ya vimos que en términos de programación es un objeto, pero conceptualmente es un evento que ocurre
durante la ejecución del programa.
Un evento que es un problema y que interrumpe el flujo normal, pero bien lo podemos manejar de tal
forma que continúe.
También capturamos el terror, lo manejamos de alguna forma, lo guardamos en el log que se yo, o damos
un camino alternativo y continuamos siempre cuando el error no sea tan grave.
Mucho lenguaje, por ejemplo, estructurados.
Cuando ocurrió un error lo que hacían era detener la ejecución de la aplicación, o bien manejaba el
error con if con else utilizando código de errores del tipo String o el tipo integer.
Y al final era bastante engorroso porque estaba todo mezclado como código espagueti de forma estructurada
con la lógica principal de nuestra aplicación.
Bueno, y justamente lo que hace Java y la programación orientada objeto es manejar los errores de forma
independiente de esa acoplada utilizando excepciones.
Bien, veamos algunas características principales que también hemos mencionado.
Separa el código que gestiona los errores del código principal de programa.
Es muy importante porque desacople nuestro código mucho más limpio y también simple y fácil de seguir.
También nos permite manejar el error y continuar con la ejecución del programa.
También lo hemos mencionado.
También permite agrupar y diferenciar entre diferentes tipos de errores.
Claro, una excepción es una instancia, es un objeto, pero de una clase especial.
Y podemos tener varias clases y podemos manejar excepciones.
Por ejemplo, utilizando true y catch.
Lo vamos a ver y capturar.
Según ese tipo, decepción es mucho más personalizado.
Otra característica es que propaga errores hacia arriba en la pila de llamada.
Esta pila se le conoce como estac 3 o también conocida como pila decepciones como por ejemplo nuestra
aplicación en la clase principal con el método main.
Podríamos invocar algún método, pero ese método a su vez internamente llama otro objeto con otro método.
Y así se van comunicando los objeto de forma cascada hasta que algún punto podría ocurrir un error en
alguna clase y método X y se podría lanzar este error o excepción.
Comienza a escalar, comienza a propagarse en cascada hacia los demás métodos hasta llegar al último
método en el cual fue llamado en la clase principal con el método Main.
Siempre cuando no se maneje o no se capture el error con el true catch en alguna clase intermedia,
bien la sintaxis true catch y finally algún método de algún objeto podría lanzar una excepción y lo
puedo manejar este error dentro del bloque try que se le conoce entonces en el TROI.
Acá se delimita el contexto donde podría ocurrir una excepción, donde se podría lanzar.
Entonces lo que hace el try es, como dice el nombre, tratar de ejecutar un código.
Bueno, y se falla.
Pasa al catch que sería la siguiente sentencia catch.
Entonces el true trata ejecutar un código.
Si todo sale bien, perfecto.
Obviamente el catch no se ejecuta, pero si se lanza alguna excepción, el catch acá puede manejar esta
acepción según un tipo atto.
Entonces es muy parecido.
Como un método se pasa por argumento el tipo o nombre de la clase de la acepción y también la variable
de la acepción.
Es decir, el objeto.
Y dentro del catch lo manejamos de alguna forma y así podemos continuar con el flujo normal.
Y también tenemos el finali, que también otra sentencia que siempre va al final después del trayec
catch bueno y siempre se va a ejecutar.
Es opcional este bloque lo podemos implementar o no. Y ahí podemos hacer algún código común si sale
bien o si sale mal.
Por ejemplo, cerrar algún recurso, alguna conexión de base dato, por ejemplo, cerrar algún archivo.
Entonces dentro del catch, ahí podemos personalizarlo.
Mensaje de error, quizás de forma más amistosa y lo podemos imprimir en la consola, en la.
Pantalla al usuario con un mensaje más resumido, por ejemplo, a la medida y así continuar con la ejecución
de nuestro programa.
Pero no solamente podemos capturar o tener un solo cache, una sola excepción, también podemos tener
en cascada varios catch y se van capturando.
Bueno, pero siempre va entrar a uno solo.
Es decir, al tipo de exepción que se lanzó entonces, según el tipo es el catch que se va a capturar.
Bueno, también está muy relacionado con la herencia.
Por ejemplo, podríamos tener una clase decepción padre e hijas y podríamos tener varios catch que atrapan
lo distintos tipos de acepciones de la jerarquía desde la clases más específica o concretas, es decir,
hijas hasta las clases más genéricas los padres.
Bueno, veamos un ejemplo de captura.
Hay múltiples excepciones.
Acá tenemos un código que primero obtenemos un valor del tipo string utilizando get option point, un
valor ingresado por el teclado, por el usuario.
Por ejemplo, un entero.
Entonces lo primero es convertir este valor, que es un tipo string que debería contener un número,
un valor entero, convertirlo a un integer.
Bien, y acá podría ocurrir, por ejemplo, o lanzarse al error number format exception.
Ya lo hemos visto en ejemplo.
Entonces el primer error que estamos capturando, que estamos manejando en caso de que ocurra.
Pero luego la idea de dividir.
Por ejemplo.
10 dividido en este divisor, en este número.
Ahora, si se convierte correctamente a un número, se divida.
Pero qué pasa si este número cero.
Recuerden que cada valor numérico dividido por cero es infinito.
Por lo tanto lanzaría una excepción aritmética exception.
No se puede ir por cero.
Entonces eso lo manejamos con un segundo catch y va en orden primero Number formas deception, que es
el primero que podría ocurrir en la conversión en el part Saint.
Luego viene el de aritmética.
Excepto con la división.
Como mencioné, cuando se lanza un excepción en nuestra aplicación, lo que se hace es lanzar una instancia,
un objeto de la clase Septo.
Pues entre clases septón opuesto una clase hija o derivada normalmente la clases hijas que heredan decepción
es para dar un tipo de error más específico, pero por lo general no agrega mucha funcionalidad extra,
solo que al ser distinto o distintas implementaciones, distintos tipos nos permiten distinguir entre
los distintos tipos, decepciones y cómo se manejan o capturar la de forma independiente en los catch.
Manejar de forma personalizada cada tipo de excepción.
Principalmente la clase septum tiene dos constructores y dos métodos importante por el constructor de
la clase es hecho.
Podemos pasar un string con el mensaje de error personalizado.
Acá lo podemos indicar, se fijan, pero también lo podemos omitir y el mensaje sería NULL.
El atributo mensaje.
Entonces tenemos forma de crear o instanciar una acepción.
Un objeto Exception y Tom-Tom importante.
Uno es el get message get message, obtener el mensaje con el detalle de error o resumen del error y
tenemos el print stack 3 que imprime la traza completa o la pila completa de las excepciones desde el
origen donde ocurre el error.
El método donde todo comienza, donde se lanza esta acepción hasta el primer método donde comienza la
llamada de los métodos, como por ejemplo podría ser una clase con el método main.
Acá tenemos la traza completa, que es muy importante para realizar el debug y poder detectar dónde
se originó el error.
Existen dos tipos de excepciones están las checked obsequiadas y checked no chequeada.
Hay una jerarquía de clases para el manejo excepciones en Java, donde todo parte de la clase excepto
la clase Exception es checked.
Esto significa que nos obliga, nos obliga a manejar la acepción, ya sea con el trait catch o bien
lanzarla en un método.
Esto significa propagar la excepción a los demás métodos que nos están invocando, es decir, derivar
el manejo de escepción al otro método que llaman al método donde ocurre la acepción y luego tenemos
el tipo hand.
Chequen o no chequeas que es de la clase Rink tan exception la clase Rank Taime Septón y su descendencia.
Las clases hijas no están obligadas al manejo de error, ocurren en tiempo ejecución, se lanzan en
tiempo ejecución, aunque igual las puedo manejar de forma explícita.
De todas forma con el trait catch, pero no estamos obligados.
Ejemplo típico el null Pointer Deception cuando una instancia null invocamos un método lanzate error
aritmético Exception.
Cuando dividimos por cero array index out of bound Exception.
Cuando se desbordan un arreglo.
Por ejemplo, queremos hacer un elemento que está fuera del límite.
En fin, number format deception.
También cuando queremos convertir un tipo string en un tipo entero.
Y por otro lado las que son chequeas que si obligan en tiempo de compilación en el IDE, por ejemplo,
a manejar el error input output exception alguna opción de entrada y salida.
Si queremos abrir algún archivo, si queremos leer algún archivo o relacionado con paseando SQL Exception,
también estamos obligado a manejar este error.
Veamos también un ejemplo.
Lo más completo de la jerarquía.
Acá tenemos el objeto Exception, que finalmente es hija de la clase Fru Haider.
Muy importante porque indica que un objeto lánzale se puede lanzar con el operador FRU.
Después vamos a ver o la sentencia FRU.
Pero también tiene un hermano la clase Exception, que es error, pero error es no chequeada.
Por lo tanto, no se maneja con el trait catch, pero son errores de sistema por falta de memoria.
O se dañó una parte del disco duro y no puede escribir alguna información, o no puede leer algún dato
que está guardado en alguna partición, por ejemplo, o errores relacionado a la máquina virtual de
Java.
Pero más bien son propios del sistema y de recursos del sistema de CPU de memoria.
En fin.
Y no nos podemos recuperar de estos errores y todo lo que sea septón de nuestra aplicación.
Y es así que le puedo manejar, ya sea reineta me section no chequeada no nos obliga a manejar estas
opciones y del tipo exception que si nos obliga que son chequeada como por ejemplo bueno, interruptor
Exception, SQL, Septón y o Exception y a su vez tenemos Not Found Exception y en ragtime.
Bueno, muchas de las que hemos visto null pointer deception aritmética exception array index out of
bonis action number fórmate hacer John.
Bueno, en general, cuando implementar una que sea checked o implementar una que sea ancha.
Claro, porque podemos personalizar y crear nuestras propias excepciones heredando ya sea deception.
Si queremos implementar una chequeada o heredar de raiting, excepto que no sea chequeada.
Entonces cuando implementar una.
Cuando implementar otra?
Bueno, hay una regla general que son para excepciones.
Checker se usa cuando nuestra aplicación se puede recuperar del error.
Es decir, es capaz de recuperarse y que lo tratemos de forma adecuada y continuar con el flujo mientras
que las han chequeé cuando ocurre algún error grave de programación y no se puede hacer nada para recuperarse.
Esa es la regla que hay.
Aunque también hay excepciones, porque también podríamos tener alguna excepción no chequeada and checked
del tipo right time.
Como en ambas formas deception y si ocurren, error.
Bueno, si no puedo convertir un string a un número, podríamos asignar un cero, por ejemplo, y poder
continuar con el flujo normal de la aplicación.
Se fijan o incluso aritmética exception se ocurre.
La solución la puedo manejar y volver a appel el dato para que el usuario vuelva ingresar el número
y esta vez no increase por ejemplo cero y puede ingresar otro número mayor que cero para que pueda ser
divisible.
En fin, hay diferentes escenarios.
Continuemos.
La cláusula frus en plural con s importante se utiliza en la declaración de métodos.
Indica que este método dentro de su contexto, de sus llaves, va a lanzar algún tipo acepcion y estos
tipos de sesiones lo tenemos que definir en el frus.
En el caso de que lanza una sola, bueno, se define una sola, pero también podría lanzar varios tipos
de secciones y ahí sería separar por coma.
Entonces en el ejemplo tenemos una clase por ejemplo cliente repositorio con el método por Heidy y podría
lanzar una acepción.
Por ejemplo, si Leydi es 0, lanza una excepción.
Bueno, y en la clase que invoca este método, ya sea una clase con el método main o cualquier otra,
tiene que manejar este error.
Entonces hay dos alternativas.
Como hemos visto, una manejar con try catch este error, esta sección, o bien propagar la excepción
hacia el siguiente método.
Entonces también te indicando que el método main posiblemente lance la excepción Exception.
Entonces los métodos deben capturar, manejar esta sección o bien propagar las o la excepción chequeada
que pueden ser lanzadas dentro de su ámbito del método.
Veamos la sentencia FROOT.
Bueno, la sentencia FRU es justamente para lanzar una acepción dentro, un método.
Acá tenemos ya el detalle de la clase cliente repositorio.
El método por Heidy y cuando el índice da igual a cero.
Creamos la instancia con New Exception y con el FRU.
Lanzamos este objeto.
Pero muy importante.
Tiene que ser del tipo Exception.
Recuerden que Exception hereda de la clase Fru Eubea.
Es decir, se puede lanzar.
No podemos lanzar con Froot.
Cualquier objetos tiene que ser del tipo Freulein.
Es decir, una excepción, ya sea Exception o una clase propia.
Nuestra personalizada que hereden de esta clase de yaba bien.
Crear una clase de excepción personalizada es bastante simple, porque solamente tenemos que heredar
Deception en caso de que queramos que sea chequeada o Checker.
O también podríamos extender de reineta es hecha si no queremos que sea chequeada, sino que sea aunt
checked.
Pero bueno, independiente de una u otra, utilizando herencia con stents.
Entonces nuestra clase hereda de Exception de forma opcional, porque no es obligación implementar el
constructor con un mensaje más personalizado.
Porque recuerden, la clase de excepción tiene dos tipos de constructores principales uno vacío que
no recibe ningún mensaje.
Por lo tanto, el mensaje en NULL y otro con el mensaje de texto.
Luego ya la podemos utilizar, por ejemplo, en nuestra clase repositorio en el método por Heidy y en
vez de lanzar un tipo genérico Exception, ya estamos personalizando y lanzando, manejando una excepción
personalizada, personalizada, excepto en este caso con un mensaje.
Aydin no puede ser cero.
Entonces saca acampemos el tipo y el tipo que se lanza también lo manejamos en el método.
Acá se declara con la cláusula FRUS para propagar la sección a los métodos que están invocando el porahí.
Entonces al final lo que hace es pasar la tarea de manejar la escepción al otro métodos a los métodos
que invocan este método.
Pero también podemos tener nuestra propia herencia.
decepcionÃ, como teníamos en el ejemplo anterior, una clase personalizada Deception que hereda.
Deception Perfecto.
Pero también podemos tener otra clase más personalizada que le podríamos llamar No cero Heidy Exception,
que hereda de Personalizada Septón se fijan y luego en nuestra clase repositorio acá podemos lanzar
el tipo más genérico, por ejemplo personalizada Deception.
Bueno, nunca bueno que sea tan tan genérico que lance excepciones, por ejemplo, sino que sea nuestra
clase más genérica pero propia nuestra que estemos implementando que debe desechÃ.
Entonces acá colocamos el tipo más genérico y lanzamos el tipo más concreto que es hija de esta clase
padre personalizada, excepto se fijan.
Entonces acá indicamos el tipo padre y acá lanzamos el tipo o la instancia hija.
O bien lanzar el hijo llega indicar el hijo en el Stroud, pero siempre mejor que sea lo más genérico
posible.
Bien sobre escritura y manejo de excepción.
Bueno, esto se aplica tanto a clases abstracta o clase padre con su reescritura de método, pero también
a implementación interfaces.
Recuerden que cuando tenemos una interfaz por ejemplo Cloud Repository, un método por Heidy.
Acá también se tiene que definir las excepciones que iba a lanzar los métodos en la jerarquía, por
ejemplo, por ahí va a lanzar personalizadas.
Y por eso importante que sea el tipo más genérico posible de nuestras implementaciones, de nuestra
jerarquía de clases, de excepciones.
Claro, porque después en la clase concreta, por ejemplo cliente repositorio, mantenemos el tipo genérico,
pero cada implementación puede lanzar su propia clase concreta, que es hija de la clase decepción más
genérica que se está lanzando, en este caso personalizada septón como no 0 hay 10 Artiom, pero así
podríamos tener distintas implementaciones, pero también.
Otra alternativa es lanzar no solamente la genética, sino también la concreta.
La hija.
Acá eso sería lo más importante.
Continuamos en la siguiente clase.