Saltar navegación

20250227Exceptions2 - Contenido educativo

Ajuste de pantalla

El ajuste de pantalla se aprecia al ver el vídeo en pantalla completa. Elige la presentación que más te guste:

Subido el 27 de febrero de 2025 por Stefano C.

4 visualizaciones

Más información Transcripción

Descargar la transcripción

Voy a grabar la segunda parte de la teoría, por lo tanto, si habláis, me autorizáis a grabar vuestra voz. 00:00:00
Vale, entonces, a continuación de lo que hemos dicho antes del bloque final, etc., etc., vamos a ver cuáles son los métodos que la clase Exception nos proporciona. 00:00:08
Entonces, hemos ya visto que existe una cosa que se llama API. Hemos visto que, sustancialmente, todas las clases ya existentes en el JDK, en el Java Development Kit de Java, pues están documentadas en este catálogo de clases, etc. 00:00:19
Es buena costumbre y deberíais aprenderla ya, cada vez que veáis una clase nueva, iros al API y echarle un vistazo. 00:00:37
Entender cuál es la filosofía de la clase, entender qué puede hacer y por qué lo hace, y sobre todo entender qué métodos tiene. 00:00:49
Veréis que después de un cierto tiempo que leéis estas cosas, pues muchas clases, hay como una filosofía detrás del Java y entonces cada vez que un método empieza con is, sabéis que devuelve un booleano y que te está preguntando si una característica es verdadera o falsa. 00:00:57
Si hay has, pues entonces está mirando algunas cosas y está viendo si hay un objeto más de una colección o de una categoría que tenga una determinada condición, etc. 00:01:19
O sea que cuanto más tiempo perdáis en leer estas cosas, más luego en un futuro vais a entender también otras clases con mayor rapidez. 00:01:32
Porque dice, ah, este es un método parecido a otro que he visto. 00:01:41
Cuando aquí, por ejemplo, han aparecido null pointer exception, number format exception, IO exception, no dudo mínimamente que vosotros hayáis ido al API del 22, no al API 17, y os habéis leído un poquito estas tres clases para entender qué son. 00:01:44
os lo voy a explicar 00:02:08
como si no lo hubieseis hecho 00:02:11
¿vale? pero sé que ya lo sabéis 00:02:13
¿sí? es que me gusta perder tiempo 00:02:15
entonces 00:02:17
en Exception hay algunos 00:02:18
métodos básicos que luego 00:02:21
hereditarán todas las demás 00:02:22
teniendo en cuenta que las otras 00:02:25
que existen como NullPointerException 00:02:27
a lo mejor puede tener métodos 00:02:29
o funcionalidades distintas 00:02:31
con respecto a Exception 00:02:33
típicas y propias solo de NullPointerException 00:02:34
Esto lo podemos saber solo mirando el API. Y por otro lado, lo veremos dentro de un ratito, nosotros podemos crear nuestras propias excepciones, ¿vale? Nuestros errores propios de nuestro programa, de nuestra aplicación, ¿vale? 00:02:37
Entonces, cuando yo me creo mi propia excepción y heredo de exception, también puedo añadir yo algunos métodos o algunas funcionalidades que dentro de mi aplicación y dentro del contexto de mi problema y dentro del contexto de esta excepción, pues tiene sentido que haya ese método. 00:02:51
Nadie me lo prohíbe. Es como una herencia normal que hemos visto ya antes. Yo estoy pillando toda otra clase y a este punto puedo usarla igual, puedo extenderla, puedo añadir cosas, puedo sobreescribir algunos de estos métodos y hacer que en vez de que haga lo básico haga otra cosa o que haga lo básico y luego una cosa más. 00:03:13
Todas estas cosas las hemos visto cuando hemos visto herencia. ¿Os acordáis? 00:03:36
Entonces, mensajitos, métodos posibles. 00:03:41
GetMessage, cada excepción, al momento de ser creada, pues se le asocia un mensaje. 00:03:45
Ese mensaje me dice más o menos una descripción genérica del problema. 00:03:52
Cuando yo alguna vez, os habéis equivocado, ha salido rojo y os he dicho, lee el error. 00:03:58
Y vosotros la primera línea os dice, ha salido un R-index autobound, has intentado acceder al número 7 de esta rama. Y había solo 6 posiciones. Esa es el message. 00:04:02
El toString lo que hace es 00:04:16
Una parte es el getMessage mismo 00:04:19
Pero le añade una 00:04:24
Sostancialmente le dice también 00:04:26
Qué clase es 00:04:29
Es una descripción del objeto 00:04:30
Así como el toString quiere ser 00:04:32
El toString es una descripción textual del objeto 00:04:35
Sobre el que se llama este método 00:04:38
ExceptionString es un constructor 00:04:42
para crear una nueva clase 00:04:44
donde este string es lo que 00:04:46
se devolverá cuando se hace el getMessage 00:04:48
o sea que yo puedo crear una nueva excepción 00:04:50
diciendo newException de 00:04:52
has tecleado mal el número 00:04:54
y eso será el 00:04:55
message que saldrá en el error 00:04:58
y luego está el printStackTrace 00:05:00
que es 00:05:02
lo que sale siempre en rojo 00:05:04
que es las 00:05:06
llamadas de las 00:05:08
varios métodos 00:05:10
desde tu método 00:05:12
Que es donde se ha verificado el error 00:05:14
A que este método por debajo 00:05:16
Llamaba otro método, que llamaba otro método 00:05:17
Normalmente las primeras una o dos líneas 00:05:19
Es parte de vuestro código 00:05:22
Y luego desde allí 00:05:24
Ya sale de vuestro código 00:05:26
Y se va a meter en alguna clase 00:05:27
De Java API que estaba por debajo 00:05:30
Que vosotros no sabéis que estáis utilizando 00:05:32
Pero en realidad si estáis utilizando 00:05:34
¿Vale? 00:05:36
Si yo hago un system.autoprintln 00:05:37
Pues por debajo estaré utilizando 00:05:40
clases que no tengo ni idea de cuáles son 00:05:42
porque no lo quiero 00:05:44
saber. Yo no quiero saber cómo se escribe 00:05:46
en pantalla. Yo quiero que todo sea 00:05:48
abstracto, todo sea 00:05:50
ocultado. Es que yo le diga 00:05:52
simplemente, escribe en pantalla y él lo hace. 00:05:54
¿Sí? ¿Dudas? 00:05:57
Algunas 00:06:02
cosas de estas pueden servir para 00:06:02
dialogar con el usuario, como el message. 00:06:04
Otras cosas, el print stack 00:06:07
trace, al usuario no se 00:06:08
lo debería decir nunca. 00:06:10
Tú escribes el Printerstack 3, el usuario colapsa porque no entiende todas esas cosas parrafadas de términos técnicos que no le interesan. 00:06:12
A él le interesa saber, no me des una palabra, dame un número. 00:06:24
Entonces, ¿cómo se lanzan las excepciones? 00:06:35
Porque, claro, nosotros hemos visto que podemos capturar las excepciones. 00:06:38
Pero, claro, ¿cómo se lanza? 00:06:42
Entonces hay dos cosillas 00:06:46
Ahora hablaremos del tema 00:06:48
Pero sostancialmente para lanzar una excepción 00:06:50
Existe el comando throw 00:06:53
Literalmente lanzar 00:06:54
Throw, catch 00:06:55
Son así de simpáticos los programadores 00:06:56
Entonces yo me puedo en un determinado momento 00:07:00
En un programa mío 00:07:03
Decir, y si pasa esta cosa de aquí 00:07:04
Créame un objeto excepción 00:07:07
Y lánzalo 00:07:10
Eso quiere decir que si llegaré a ese punto de la ejecución del código, asumo que mi método ha acabado porque ha habido un error y que voy a avisar posiblemente el llamante de este método. 00:07:11
Quien ha llamado a este método ha ejecutado hasta aquí. Aquí ha habido el error y ahora yo te aviso a ti, llamante, que ha pasado algo, que ha habido un error. 00:07:28
y hay dos opciones 00:07:38
o el llamante 00:07:40
había hecho la llamada en un try catch 00:07:42
y entonces si yo lanzo la excepción 00:07:44
él la recoge y hace lo que tiene que hacer 00:07:47
o el llamante 00:07:50
no estaba en un try catch 00:07:53
y por lo tanto él también no sabe cómo seguir 00:07:55
y elevará esta excepción 00:07:58
a quien ha llamado a él 00:08:01
para arriba, para arriba, para arriba, para arriba 00:08:03
hasta llegar a un momento en que llegas al main 00:08:07
y si el main lanza una excepción 00:08:08
nadie la puede recoger 00:08:11
y se cierra todo 00:08:12
entonces si yo tengo el main 00:08:14
que llama el método 00:08:18
calculaDivision 00:08:20
que llama el método 00:08:22
leeteUnNumero 00:08:23
y resulta que cuando lee un 0 al denominador 00:08:26
pues lanza una excepción 00:08:29
de esta, este lanza 00:08:30
la recoge el método 00:08:32
del medio que dirá 00:08:34
si tiene un try catch pues hará lo que tiene 00:08:36
que hacer, como por ejemplo, avisar al usuario 00:08:38
mira, los datos que me has dado no son correctos 00:08:40
e intentarlo otra vez, si en vez de 00:08:42
no tienen un try que he hecho, pues lo que hará es 00:08:44
pasarlo al main, el main dirá, ya está 00:08:46
y a ese punto, el error 00:08:48
como estamos acostumbrados a verlos 00:08:50
en los ejercicios 00:08:52
que hemos hecho antes de manejar 00:08:54
excepciones, dudas? 00:08:56
vale 00:09:00
el objeto que se pasa a throw 00:09:00
tiene que ser de la clase exception 00:09:02
o de cualquier subclase que la 00:09:04
extienda, vale, incluyendo excepciones 00:09:06
personalizadas, que veremos a continuación 00:09:08
dudas hasta aquí 00:09:10
entonces si en algún lado puedo hacer throw 00:09:12
throw, cuando lanzo 00:09:14
el throw se sale inmediatamente del bloque del código 00:09:16
actual, si yo estaba en un bloque, cuando ejecuto 00:09:18
el throw, este bloque se ha acabado 00:09:20
salgo 00:09:22
si el bloque tiene asociado 00:09:23
a una cláusula catch, vale, o sea 00:09:27
estoy en un try catch, pues adecuada 00:09:28
para el tipo de recepción 00:09:30
generada, se ejecuta el cuerpo de la 00:09:32
cláusula catch, si no, no 00:09:34
si no, se sale 00:09:36
inmediatamente del bloque o del método 00:09:38
dentro del cual se está 00:09:40
en el que se produjo la etc 00:09:42
y se busca la cláusula catch 00:09:44
apropiada, o sea, lo que decía que 00:09:46
se va por arriba, tú tienes un try catch 00:09:48
no, se va por arriba, tú tienes un try catch 00:09:50
no, para arriba, hasta llegar 00:09:53
a alguien que lo tenga o llegar al main 00:09:54
el proceso continúa 00:09:56
hasta llegar al método main de la aplicación 00:09:58
si allí tampoco existe una cláusula catch 00:10:00
adecuada, la máquina virtual 00:10:02
de Java finaliza su ejecución 00:10:04
con un mensaje de error 00:10:06
¿es el método 00:10:07
llamante 00:10:14
el que tiene 00:10:15
que gestionar la 00:10:18
posible excepción 00:10:20
de un método llamado? 00:10:22
pregunta 00:10:34
¿es el método 00:10:35
llamante 00:10:40
el encargado 00:10:41
de gestionar 00:10:43
la excepción 00:10:44
la posible excepción 00:10:46
de un método llamado 00:10:48
porque es falso 00:10:51
puede gestionarlo más abajo 00:10:53
y puede gestionarlo más arriba 00:11:00
puede ser el mismo método llamado 00:11:02
que se gestione de alguna forma 00:11:06
el error 00:11:08
y puede ser que no sea yo el llamante 00:11:09
más sea 00:11:11
quien me ha llamado a mi 00:11:12
o puede que no sea 00:11:14
gestionado. ¿Dudas? 00:11:17
Vale. 00:11:24
Luego está TRUE. 00:11:25
¿Vosotros 00:11:28
que sabéis el inglés 00:11:29
podéis notar la diferencia? 00:11:30
Efectivamente. 00:11:35
¿Es una S de plural 00:11:37
o una S de tercera persona? 00:11:39
Eso. 00:11:42
¿Vale? 00:11:43
Nosotros podemos definir 00:11:45
en el código de un método F 00:11:47
cuando nosotros decidimos 00:11:49
hacemos el prototipo vale cuando nosotros definimos public void mi método con estos 00:11:51
parámetros allí le podemos decir y este método lanza puede lanzar esta excepción entonces le 00:11:59
ponemos throws y esta excepción vale como aquí public void método f throws esto es como avisar 00:12:08
quién va a utilizar f 00:12:18
que en algún lado 00:12:20
de este código es posible 00:12:23
que ocurra una excepción 00:12:25
entonces yo que voy a usar 00:12:27
f y sé que puede 00:12:31
lanzar una excepción e 00:12:32
pues de tipo e 00:12:35
puede ser null pointer exception 00:12:36
o lo que sea 00:12:39
pues lo que hago es que cuando 00:12:40
llamo f lo pondré en un 00:12:42
try catch con un catch 00:12:45
de esta posible excepción 00:12:46
Pero en un cierto senso lo estás haciendo. Solo que tú estás diciendo a quien va a usar F, cuidado, esto puede pasar. Gestionalo tú. No lo estoy gestionando yo. Esto no está gestionado en el método F, porque si no, me lo pongo y lo hago yo. 00:12:48
Ahora, también es posible que yo te esté diciendo 00:13:17
Yo no sé cómo lo quieres gestionar 00:13:20
Yo te estoy diciendo que puede ocurrir 00:13:22
Te estoy avisando que esto es un problema posible 00:13:25
Ahora, ¿cómo lo quieres gestionar? 00:13:30
Pues eso es un problema tuyo 00:13:33
Puedes ignorarlo, puedes intentarlo otra vez 00:13:34
Puedes que si ocurre ese error 00:13:37
Puedes pillar un valor por defecto 00:13:39
En vez de utilizar el valor que estabas intentando calcular 00:13:41
Puedes avisar el usuario 00:13:44
Puedes escribir en un 00:13:46
Tú decides que se hace 00:13:47
Yo te estoy diciendo que puede pasar 00:13:49
Si en el código método F 00:13:51
Se lanza una excepción de clase E 00:13:56
En el prototipo del método 00:13:57
Debemos indicarlo con la palabra reservada throws 00:13:59
Esto sirve para que 00:14:02
Potenciales usuarios de F 00:14:04
Sepan a qué atenerse 00:14:06
Sepan que F puede lanzar esto 00:14:07
Lo veremos cuando por ejemplo 00:14:10
Veremos los accesos a ficheros 00:14:11
Y veremos que leer de fichero 00:14:13
puede causar una IOException 00:14:16
y entonces tú cuando usas 00:14:18
la read para leer en el fichero 00:14:20
tendrás que meterla en un try-catch 00:14:22
y gestionar una eventual 00:14:24
explosión de la IOException 00:14:26
no me acuerdo 00:14:28
creo que no 00:14:38
creo que eso era un warning 00:14:40
a otro nivel, ¿vale? 00:14:44
porque este de aquí, y ahora veremos 00:14:46
ahora hilamos más fino 00:14:47
hay algunas excepciones que si tú no la controlas 00:14:49
no pasa nada, pero hay otras excepciones 00:14:52
Que estás forzado a controlarla 00:14:54
Te da error si no la controlas 00:14:56
Ahora llegamos a eso 00:14:58
Si un método lanza más de un tipo de excepciones 00:14:59
Se indicarán detrás de trolls separados por coma, ¿vale? 00:15:02
Entonces, este método de aquí lanza esto y esto y esto y esto y esto 00:15:05
Controlas tú 00:15:10
Lanzar excepciones, ¿vale? 00:15:15
Cuando en un código utilizamos métodos que lanzan potencialmente excepciones 00:15:17
Tengo dos opciones, ¿vale? 00:15:21
O sea, tengo un método, tengo un código que utiliza métodos que lanzan potenciales excepciones, ¿vale? 00:15:24
Es decir, que estos métodos que estoy utilizando tienen un trowse, ¿vale? 00:15:34
Puede hacer dos cosas. 00:15:38
O proteger la llamada de este método con un try-catch. 00:15:40
O sea, yo tengo mi código, pongo try, lanzo el método que puede explotar, catch, recojo la explosión. 00:15:43
¿Sí? O la segunda opción es el código que yo estoy haciendo, asumiendo que sea un método, decir que también este método puede lanzar esa excepción. 00:15:49
Entonces, si el método que he llamado lanza una IOException, yo en vez de recogerla digo, vale, si pasara, yo también lanzo esta. 00:16:00
Sustancialmente paso la pelota a quien me ha llamado. 00:16:11
A veces puede tener sentido principalmente de cara a si tu método es tan genérico que no sabes cómo en la aplicación quieres arreglar 00:16:15
este posible problema, pues entonces dice 00:16:30
vale, el método sigue aquí 00:16:32
sé que puede pasar este error cuando 00:16:34
llamo este método de aquí, por lo tanto digo 00:16:36
también yo puedo generar este error 00:16:38
que sea quien me ha llamado a mí 00:16:39
el que gestione según la aplicación 00:16:42
que está haciendo 00:16:44
sí, más o menos 00:16:44
el concepto es siempre el mismo 00:16:47
¿vale? o sea, el error se 00:16:50
crea en un lado y luego se va 00:16:52
escalando hacia arriba hasta 00:16:54
o encontrar un try catch 00:16:56
que lo recoja con el catch 00:16:58
correcto 00:17:00
o el catch 00:17:01
del tipo 00:17:02
de la excepción que ha saltado 00:17:06
o un padre 00:17:08
una super clase 00:17:10
de esa excepción 00:17:12
o va para arriba 00:17:13
hasta llegar al main y el main cierra todo 00:17:15
esto delega la responsabilidad del manejo 00:17:18
a otras clases invocantes 00:17:23
y de allí tiene el sentido del 00:17:25
print stack trace 00:17:27
porque si esto crea la excepción 00:17:28
y luego lo pasa al llamante 00:17:31
que dice lo lanzo por arriba 00:17:33
que lo lanza por arriba 00:17:35
se está creando una pila 00:17:36
de llamadas 00:17:39
y el printStackTrace 00:17:40
lo que me hace es la traza 00:17:43
de esta pila para decir quién ha llamado 00:17:45
quién y quién ha explotado quién 00:17:47
y cómo hemos llegado 00:17:49
aquí, yo tenía este método 00:17:51
que había llamado esto, que había llamado esto 00:17:53
este ha generado el error 00:17:54
que le ha pasado a esto y este no lo ha gestionado 00:17:57
le ha pasado a este, este no lo ha gestionado 00:17:59
le ha pasado a este, este no lo ha gestionado 00:18:01
era el main ha explotado 00:18:02
pero te estoy diciendo lo que ha pasado 00:18:03
si la excepción lanzada es hija 00:18:07
de runtime exception, no es necesario 00:18:11
manejarla 00:18:13
o sea, yo tengo exception 00:18:16
tendré un montón de excepciones 00:18:18
pero tendré también una 00:18:21
excepción particular que es runtime exception 00:18:22
la excepción 00:18:26
que explota es runtime exception 00:18:28
o hija de runtime exception, no es necesario 00:18:31
poner un try-catch. Eso no quiere decir 00:18:35
que funcionaría. No. Explota igualmente. 00:18:38
Pero no te fuerza a explotar, 00:18:41
a manejarla. Y os hago una pregunta. 00:18:43
¿Vosotros conocéis null pointer exception? 00:18:47
¿Conocéis a reindex out of bound exception? 00:18:50
¿Cuántas veces os ha pasado 00:18:53
y no lo habéis puesto en un try catch 00:18:56
siempre, vale 00:18:58
y Java no te avisa 00:19:02
oye mira, tienes un array 00:19:04
podrías leer 00:19:06
fuera de los rangos 00:19:08
haz un try catch para un array 00:19:10
index out of bound 00:19:12
Java no te avisa 00:19:14
diciendo, oye mira tienes un objeto 00:19:16
podría ser null, no lo uses 00:19:17
antes comprueba que no es null 00:19:20
o ponlo en un try catch y pilla 00:19:21
en el pointer exception, ¿por qué? 00:19:24
Porque tanto null point of exception como array index of exception derivan de runtime exception. 00:19:25
Son excepciones tan comunes que sería una sobrecarga extrema estar pendiente de ellas constantemente. 00:19:33
Entonces se asume que no lo tienes que hacer, lo tienes que comprobar, 00:19:45
Tienes que tener cuidado con estos 00:19:50
Pero si no lo haces 00:19:53
No te voy a bloquear 00:19:55
No te voy a dar un error en tiempo de compilación 00:19:56
Diciendo, eh, no has comprobado 00:19:59
Que aquí podría saltar una null pointer exception 00:20:01
Todas las runtime exceptions 00:20:03
Son de este tipo 00:20:05
Pueden explotar, pueden pasar 00:20:06
Pero si tú no las manejas 00:20:09
Allá tú 00:20:11
A ver, eso es un warning 00:20:12
Y eso deriva de 00:20:33
Abrir y cerrar recursos 00:20:35
que nosotros todavía no sabemos que son 00:20:37
porque no sabemos de 00:20:39
stream, no sabemos 00:20:40
que es un input stream o un output stream 00:20:43
no sabemos si escribir en fichero, no sabemos si escribir 00:20:45
no entendemos muy bien 00:20:47
esto de recibir datos 00:20:49
desde Scanner, que hace Scanner no lo sabemos 00:20:50
por lo tanto por ahora lo dejamos allí 00:20:53
en el aire, ¿vale? 00:20:55
posiblemente 00:20:57
no me acuerdo exactamente el error que te da 00:20:58
¿vale? pero sostancialmente 00:21:00
cuando tú abres una lectura 00:21:02
desde el teclado deberías 00:21:05
cuando ya no la usas más, cerrar el recurso 00:21:06
para evitar memory leak 00:21:09
¿vale? dejar de haber 00:21:10
dejado allí un objeto scanner 00:21:12
que no vas a utilizar nunca jamás 00:21:15
pero que te ocupa memoria, porque tienes 00:21:16
una referencia y luego en un 00:21:18
ciclo siguiente construyes otro y lo 00:21:21
dejas allí, construyes otro y llega un momento 00:21:22
que tienes un montón de objetos con referencias 00:21:25
que pero no usarás nunca 00:21:27
¿vale? entonces en un cierto sentido te está diciendo 00:21:28
cuando ya la has usado, lo deberías 00:21:31
cerrar ¿vale? ahora 00:21:33
no sé 00:21:35
No creo que cerrarlo te pueda lanzar 00:21:35
Una excepción, no me acuerdo 00:21:39
¿Vale? 00:21:41
No, pero eso es un try con recursos 00:21:55
Él hace un try abierta paréntesis 00:21:57
Pone allí el escáner 00:22:00
Cerrada paréntesis 00:22:02
Y luego hace una cosa 00:22:03
Es una cosa un poquito distinta 00:22:05
Es una versión de try un poquito más compleja 00:22:07
Existe el try con recursos 00:22:09
Donde tú, cuando lanzas el try 00:22:11
Aquí 00:22:14
Entre esto y esto 00:22:15
declaras unos recursos 00:22:17
esos recursos solo existirán 00:22:20
dentro de este bloque 00:22:22
de aquí, y cuando acaba el bloque 00:22:24
o acaba el final o cosas por el estilo 00:22:26
se cerrarán de forma automática 00:22:28
y se utiliza mucho 00:22:30
en cosas como scanner, como 00:22:32
lectura de ficheros 00:22:34
como mandar cosas por internet 00:22:36
etc, etc, etc, vale, pero 00:22:38
por ahora a nosotros nos interesa 00:22:40
relativamente poco 00:22:42
no los necesitamos 00:22:42
por ahora. Entonces, jerarquía de excepciones, para entender un poquito cómo es, existe 00:22:47
el concepto de throwable, o sea, un objeto lanzable. Dentro de throwable hay dos tipos 00:22:55
de cosas que heredan de throwable, que son errores y excepciones. Error and exception. 00:23:04
Error es un error grave. Es un error grave que no debería ser manejado. 00:23:12
No es un, oye, mira, te has equivocado a escribir el nombre y has empezado por número. 00:23:17
O, oye, mira, te he pedido un número y me has dado una letra. 00:23:23
No, es un error de la Java Virtual Machine. 00:23:29
La Java Virtual Machine se ha quedado sin memoria. 00:23:31
Has intentado acceder a una zona de memoria que el sistema operativo no te permite. 00:23:34
Son cosas que no deberían ser manejadas porque son tan graves que no te recuperes de eso. 00:23:40
Hay un error serio. 00:23:47
Sal. 00:23:48
Eso es un error. 00:23:49
Sin embargo, luego están las exceptions, que son los errores manejables o recuperables más relacionados con lo que estoy haciendo yo. 00:23:52
Eso de que, oye, mira, el Java Termination está funcionando, el sistema está funcionando, pero ha habido un error en tu aplicación. 00:24:00
Haz algo para recuperarlo 00:24:09
Y dentro de Exception hay dos tipos 00:24:11
Hay el Runtime Exception y las demás 00:24:15
El Runtime Exception son errores habituales de ejecución 00:24:18
Y como son tan habituales y debería estar constantemente mirando 00:24:22
Si eso pasa o no, pues llega un momento en que no está obligado 00:24:26
A declarar su manejo o vigilarlo o cosas por el estilo 00:24:30
Sería un costo computacional demasiado grande 00:24:34
estar constantemente vigilando 00:24:39
todos los accesos 00:24:41
a todos los arrays y todos los 00:24:43
objetos que no se anule, cosa por el estilo. 00:24:45
¿Vale? Por lo tanto, dice 00:24:47
hazlo tú. ¿Vale? 00:24:49
Arithmetic exception, 00:24:52
index out of bound 00:24:53
exception, null pointer exception, 00:24:55
son todos ejemplos de runtime exception. 00:24:57
Y luego están los demás. 00:25:00
Las demás excepciones 00:25:02
sí estás obligado 00:25:03
manejarlas. 00:25:06
¿Vale? Es decir, que si yo lanzo una excepción que no sea una RuntimeException, si yo no lo meto, el método que lanza esa excepción, no lo meto en un TryCatch, pues no me va a funcionar, me va a dar un error a tiempo de compilación. 00:25:09
Me va a decir, mira, estás usando este método, este método está declarado que throws esta excepción, esta excepción no es del tipo de RuntimeException, por lo tanto, si quieres usar este método, necesitas ponerlo en un TryCatch. 00:25:24
Ir y cachear esta posible excepción 00:25:39
Entonces, excepciones que obligan a quien use código que las pueda lanzar 00:25:46
Las maneje o avisa a los demás 00:25:52
Siempre tengo las dos opciones 00:25:56
O, vale, muy bien, uso este método aquí, este método es peligroso 00:25:58
Lo gestiono yo 00:26:03
O, oye, mira, uso este método, este método es peligroso 00:26:04
Y el mismo peligro 00:26:08
Lo hago mío 00:26:10
En el sentido, si él throws 00:26:11
No sé qué exception 00:26:13
Pues yo también throws no sé qué exception 00:26:15
De esta forma, si explota él 00:26:18
Pues yo voy a pasar la pelota 00:26:20
A quien me ha llamado a mí 00:26:22
Ya está 00:26:24
Por ejemplo, CertificationAutoException 00:26:24
CloneNoSupportedException 00:26:28
Y otros más, ¿vale? 00:26:30
Esto es un poquito un esquemita generalizado 00:26:31
De object 00:26:33
De object viene throwable, error 00:26:35
posibles errores, como por ejemplo 00:26:37
out of memory error, oye, se ha acabado 00:26:40
la RAM, no es que tú te puedas 00:26:42
recuperar del hecho que se ha acabado la RAM 00:26:44
¿sí? 00:26:46
stack overflow 00:26:49
error, ¿vale? 00:26:50
este de aquí os puede sonar 00:26:52
de algo, stack overflow 00:26:54
suena 00:26:56
a web, ¿vale? viene de aquí probablemente 00:26:56
stack overflow, la stack es 00:27:00
esta pila de llamo, que llamo, que llamo 00:27:02
que llamo, que llamo, que llamo 00:27:04
que llamo, que llamo, que llamo 00:27:05
y que pasa si yo 00:27:07
hago un while true donde dentro 00:27:08
llamo este mismo método 00:27:11
que se vuelve a llamar, se vuelve a llamar, se vuelve a llamar 00:27:13
llega un momento en que la stack 00:27:17
la pila de llamadas 00:27:19
se llena, porque estamos 00:27:20
en un ordenador y todos los recursos 00:27:23
de un ordenador son finitos 00:27:25
no hay ordenadores 00:27:27
con recursos infinitos 00:27:29
puede tardar menos o más 00:27:30
pero llega un momento en que se... 00:27:32
Y si yo llego allí, he hecho tantas llamadas 00:27:34
Que cuando llego a la siguiente 00:27:37
No la puedo hacer porque no tengo 00:27:39
Los recursos, pues salta 00:27:41
Un Stack Overflow error 00:27:43
¿Y qué hago? ¿Cómo me recupero? 00:27:45
No me puedo recuperar, es que tengo una pila que está creciendo 00:27:47
Demasiado, ¿vale? El error es tuyo 00:27:49
Pero es que el sistema no se puede 00:27:51
Recuperar de eso 00:27:53
Luego están las Exception 00:27:54
De Exception están 00:27:57
La Runtime Exception, que son 00:27:59
Estas muy, muy comunes 00:28:01
Y entonces no tengo que gestionarlas 00:28:03
Y aquí hay ArithmeticException 00:28:06
Como por ejemplo cuando hago una división por cero 00:28:08
Creo 00:28:10
Hay NegativeArraySizeException 00:28:10
NullPointerException 00:28:14
NoSuchElementException 00:28:16
Creo que NoSuchElementException 00:28:18
Salía en algún lado de Scanner 00:28:20
Puede ser 00:28:24
IndexAutoBoundException 00:28:24
Etcétera, etcétera 00:28:29
Y luego están estas otras 00:28:30
Estas otras son excepciones básicas 00:28:32
Como por ejemplo la Class Not Found Exception 00:28:34
La Interrupted Exception 00:28:37
La End of File Exception 00:28:39
La... 00:28:41
Todas estas son I.O. Exception 00:28:42
Aquí volveremos cuando empezaremos a ver algo de entrada-salida 00:28:45
De escribir y leer de ficheros 00:28:49
Entonces saldrán estas cosas de aquí 00:28:51
¿Dudas? 00:28:53
Vale 00:28:58
Nos queda reciente poco 00:28:59
Para empezar a probar algunas de estas cosas 00:29:01
Existen también las excepciones personalizadas 00:29:05
O sea, en algún momento yo puedo crear mis propias excepciones 00:29:09
Una excepción es una clase, ¿vale? 00:29:13
Simplemente hago public class a mi excepción standException 00:29:15
Y he creado una nueva clase 00:29:18
Si standException soy de esas que tienen que ser controladas 00:29:21
Si standRuntimeException, pues son de estas que no hace falta que sea controlada 00:29:25
Lo que se suele hacer cuando se crea una excepción personalizada 00:29:34
Es crear un constructor del estilo 00:29:39
Mi excepción pilla un string y lo que hace es super s 00:29:41
Hace lo mismo que hace exception 00:29:46
Porque al fin y al cabo la excepción lo que interesa es que tenga un mensajito de error 00:29:49
De esta forma se pueden crear objetos de esta clase con un mensaje personalizado 00:29:52
Asociado al método getMessage que luego puedo sobreescribir o puedo utilizar directamente 00:29:58
El de exception 00:30:03
Este es un ejemplo 00:30:05
¿Vale? 00:30:07
Yo tengo public 00:30:08
Divide by zero exception 00:30:09
Que extiende arithmetic exception 00:30:11
Por ejemplo, he extendido 00:30:14
Esta 00:30:16
Aquí le he colgado debajo 00:30:16
Una 00:30:21
Excepción particular 00:30:22
Que no es aritmética en general 00:30:25
Pero es dividir por cero 00:30:27
Que sostancialmente 00:30:29
Tiene un constructor, divide by zero exception 00:30:31
String message, super message 00:30:33
Y luego aquí tengo un public double dividir 00:30:36
Que pilla dos números 00:30:41
Y puede lanzar divide by zero exception 00:30:42
Entonces cuando alguien usa dividir 00:30:46
Sabe que se puede encontrar con una división by zero 00:30:49
Si el denominador es cero 00:30:55
Pues entonces este método lanzará 00:30:59
Un nuevo objeto 00:31:02
DivideByZeroException con escrito 00:31:03
Error 00:31:06
O podría escribir has dividido por cero 00:31:06
O denominador no válido 00:31:09
Si no 00:31:12
Como esto 00:31:14
Como si tuviera aquí 00:31:16
Una corchete corchete 00:31:17
Pues entonces devolverá la división 00:31:19
Lo das 00:31:21
Se entiende 00:31:24
Y con esto se acaba la teoría 00:31:26
Materias:
Programación
Niveles educativos:
▼ Mostrar / ocultar niveles
  • Formación Profesional
    • Ciclo formativo de grado superior
      • Primer Curso
Autor/es:
Stefano Chiesa
Subido por:
Stefano C.
Licencia:
Reconocimiento - No comercial
Visualizaciones:
4
Fecha:
27 de febrero de 2025 - 12:51
Visibilidad:
Clave
Centro:
IES ROSA CHACEL
Duración:
31′ 34″
Relación de aspecto:
16:10 El estándar usado por los portátiles de 15,4" y algunos otros, es ancho como el 16:9.
Resolución:
1152x720 píxeles
Tamaño:
77.66 MBytes

Del mismo autor…

Ver más del mismo autor

EducaMadrid, Plataforma Educativa de la Comunidad de Madrid

Plataforma Educativa EducaMadrid