Hola desde luego nuevamente Ubaldo Acosta espero que estén listos para comenzar con esta elección.
A continuación vamos a ver más respecto al tema decepciones en Java están listos.
Vamos la cláusula throws en esta elección vamos a continuar revisando más temas acerca de las excepciones
en Java.
Vamos a hablar ahora de la cláusula throws la cual nos permite especificar el tipo de decepción que
arroja cierto método.
Esto se puede deber a que el método no atrapó la excepción y por lo tanto se va a propagar al método
que lo manda llamar.
Una excepción que extiende Deception.
Si estamos obligados a declararla en la firma del método ya que ese tipo de excepciones al igual que
cuando comentábamos que se deben procesar por un bloque y coach si no son procesadas por este bloque
entonces estamos obligados a declararlas dentro del método donde se hace uso del método que arroja la
excepción una excepción que extiende de runtime exception.
No estamos obligados a declararla en la firma del método al usar un método que arroje ese tipo de excepciones
la cláusula Zou vamos a revisar ahora la cláusula drow esta palabra reservada nos permite lanzar explícitamente
una excepción por ejemplo podemos utilizar una clase de excepción que viene de la clase exception o
cualquier otra clase de tipo acepción y en conjunto con el operador Niu crear un nuevo objeto de esta
clase y así arrojar una excepción de manera explícita en el código podemos observar como dentro del
método X se lanza una nueva excepción del tipo exception utilizando la palabra reservada Zou seguida
de la clase de tipo exception que queremos instancias.
Normalmente las clases de excepción en su constructor tienen una cadena que será el mensaje que se mandará
al esta actriz al momento en que ocurra el problema o se lance la excepción.
Posteriormente lo que observamos es que el método main al hacer uso del método X obliga a procesar la
excepción por medio de un bloque Reixach o a declarar en la firma del método que el método X puede llegar
a lanzar la excepción de tipo exception.
Y esto lo veremos en la firma del método por medio de la palabra throws exception.
De hecho con un proceso similar es como nuestra aplicación puede convertir excepciones de tipo exception
es decir cheat excepciones a excepciones de tipo runtime exception es decir un check exception crearon
nuestras propias clases de tipo runtime reception y al momento de envolver una excepción de tipo exception
con un bloque 30h se puede relanzar una excepción de tipo runtime section.
De esta manera no obligamos a los métodos que utilicen nuestros métodos a que declaren el tipo de excepción
que se puede arrojar ya que se han convertido a tipo runtime exception creación de nuestras propias
clases excepción
vamos a ver a continuación cómo podemos crear nuestras propias clases de recepción las cuales pueden
extender la clase exception Orueta y reception o incluso extender de alguna clase de decepción que nosotros
hayamos definido la intención de crear nuestras propias clases decepción es personalizar los mensajes
de error que se envían al usuario por ejemplo un error de base de datos se puede atrapar y convertir
en un mensaje de error legible al usuario que usa nuestra aplicación o como hemos comentado anteriormente.
Podemos crear clases de excepción que desciendan de la clase runtime exception para no obligar a los
usuarios a usar bloques y catch o declarar en la firma de los métodos el tipo de decepción que arrojará.
En caso de que suceda alguna excepción del tipo que hemos declarado como hemos observado en el código
estamos creando una clase de tipo ni excepción la cual hereda de la clase exception.
Sin embargo puede extender de cualquier otra clase de excepción que nos interese posteriormente.
Esta clase contiene un constructor el cual recibe el mensaje que nos servirá para inicializar el atributo
mensaje de la clase padre mandando a llamar el constructor Padre por medio de la palabra super y con
esto queda inicializar a nuestra clase de tipo exception posteriormente en la clase arrojar excepción
dos podemos observar que si lanzamos una excepción de tipo ni excepción y como es de tipo exception
se obliga al método X a declarar en su firma el tipo de acepción que se lanzará en caso de error.
Así es como crearemos nuestras propias clases de excepción y así también es como las usaremos dentro
de nuestro código IAVA
uso de excepciones utilizando herencia
vamos a revisar ahora el tema de uso de excepciones utilizando herencia en el código mostrado vemos
dos clases una llamada mi excepción la cual extiende de la clase exception.
Posteriormente declaramos una clase llamada Mi acepción hija la cual es una subclase de mi acepción
por lo tanto tenemos una jerarquía de clases de excepciones que hemos creado.
Por otro lado en la clase arrojar excepción 3 se arroja una subclase llamada Mi acepción hija dentro
del método X pero si observamos la firma del método el método declara que se arroja una excepción que
es una superclase llamada ni acepción.
La intención de hacer esto es que el método internamente puede arrojar excepciones que son subclases
pero la clase que use a este método sólo procesa la acepción más genérica y con ello podemos tener un
rango más amplio para el manejo de excepciones utilizando precisamente el concepto de herencia pero
ahora dentro de la definición de clases de tipo exception y al igual que cuando trabajamos con polimorfismo
mucho del código en cualquier lenguaje de programación y también en el lenguaje Java es crear métodos
lo más genérico posibles que nos ayuden a englobar más posibilidades de excepción en menos líneas de
código que al final nos ahorrará costos de mantenimiento en nuestras aplicaciones al tener código lo
más genérico y compacto posible
uso de excepciones en la sobrecarga de métodos
vamos a ver a continuación el uso de excepciones al momento de sobrecargar nuestros métodos en Java.
Algunas de las reglas que debemos respetar son un método que describe a un método padre que declara
una excepción puede hacer lo siguiente No arrojar ninguna excepción es decir omitir la excepción en
su firma.
Arrojar una o más excepciones arrojadas por el método padre arrojar una o más excepciones que son subclases
de la acepción arrojada un método que describe a un método padre que declara una excepción no puede
arrojar excepciones adicionales no arrojadas en el método padre.
Arrojar superclase es de las excepciones arrojadas por el método padre en el código mostrado.
Observamos una clase padre arrojar excepcional y dos clases hijas arrojar XB y arrojar XC las cuales
describen el método X definido por la clase padre lo que estamos aclarando en este código son las excepciones
que podemos utilizar en la firma de los métodos sobre escritos por las clases hijas.
Por un lado observamos que la clase arrojar XB en la firma del método x en lugar de utilizar la misma
excepción que en la firma del método de la clase padre ni excepción se utiliza una subclase ni acepción
hija.
De esta manera es claro que no necesariamente debemos utilizar la misma clase decepción en la firma
del método sino que puede ser alguna otra clase dentro de la jerarquía de clases de excepción que estamos
utilizando siendo siempre subclases y no súper clases.
Por otro lado observamos en la clase arrojar XP que se utiliza precisamente una súper clase exception
de la clase excepción utilizada en la clase padre ni excepción y por lo tanto esto no es válido y existe
un problema de compilación en nuestro código.
Más adelante veremos un ejemplo de ese tipo de manejo de excepciones en la firma de los métodos que
se.