Saltar navegación

Exception - 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 30 de enero de 2026 por Stefano C.

5 visualizaciones

Más información Transcripción

Descargar la transcripción

Voy a grabar esta clase, por lo tanto, si habláis, me autorizáis a grabar vuestra boca. 00:00:00
Entonces, lo que vamos a ver hoy es el concepto de manejo de excepciones. 00:00:10
Nosotros hemos visto en programas anteriores que a veces Java no consigue hacer lo que tiene que hacer. 00:00:14
Aquí hay varios tipos de errores, varios tipos de problemas. 00:00:24
El primer error, y más fácil, son los errores sintácticos o, dicho de esta forma, los errores resolvibles a tiempo de compilación. 00:00:28
Eso porque Java, ¿cómo es Java? ¿Interpretado o compilado? 00:00:38
Six, seven. 00:00:43
¡Six, seven! 00:00:44
Ambas. 00:00:46
Ambas, ¿vale? 00:00:48
Entonces, si os acordáis, antes se compila en bytecode y después se interpreta desde bytecode. 00:00:49
El compilador, la fase de compilador, una cosa interesante que nos proporciona 00:00:55
es que sustancialmente nos permite encontrar pequeños errores de sintaxis. 00:00:58
O sea, si yo he escrito mal el código, él me lo marca y me dice, 00:01:06
no, mira, aquí esta palabra no podía estar. 00:01:10
Oye, mira, has usado una variable, esta variable no existe, no la has declarado antes. 00:01:12
Oye, estás llamando un método y este método no existe, no lo has declarado. 00:01:15
Todas estas cosas son las cosas que os salen en el IDE, os salen en Eclipse. 00:01:20
marcadas en rojos hay un error 00:01:23
y vosotros 00:01:26
sin ni siquiera haber 00:01:28
arrancado el programa 00:01:30
ya sabéis que ese programa no va a funcionar 00:01:32
y que necesitáis modificarle 00:01:34
cambiar 00:01:36
una vez que no tenéis errores 00:01:36
de compilación, no tenéis 00:01:40
marcado nada de rojo 00:01:42
lanzáis vuestro programa y vuestro programa funciona 00:01:43
seguramente, correcto 00:01:46
arranca 00:01:48
se ejecuta 00:01:52
Pero luego podría no hacer para nada lo que vosotros queréis que haga. 00:01:54
Vosotros habéis hecho un programa para calcular el área del triángulo 00:02:01
y lo que hace es calcular lado por lado. 00:02:04
El programa funciona, te da un resultado, tú le pones lado 3 y se te dice, 00:02:08
claro, 3 por 3, 9. 00:02:12
Pero esa no es el área del triángulo, es el área del cuadrado. 00:02:13
Estos son errores semánticos. 00:02:19
y eso no hay nadie que os lo resuelva. 00:02:21
Esos son problemas vuestros. 00:02:26
Habéis programado mal. 00:02:28
Eso es entender cuál es el problema, 00:02:31
entender cuál es el algoritmo para solucionarlo 00:02:34
e implementarlo bien. 00:02:36
Si hacéis errores en el algoritmo, 00:02:38
el problema es vuestro. 00:02:40
Y luego está un tercer tipo de errores, 00:02:44
digamos así, ¿vale? 00:02:47
Que son cosas que técnicamente estarían bien, pero que en esa situación concreta de esa ejecución 00:02:48
ha pasado algo que sustancialmente los ha transformado en mal. 00:03:01
¿Me explico? 00:03:07
Por ejemplo, yo te he dicho, dame un número, y tú has escrito gato. 00:03:08
¿Vale? 00:03:12
Mi código no tenía errores semánticos. 00:03:13
Mi código no tenía errores sintácticos. 00:03:16
Mi código es sólido, pero en el momento en que yo te pido un número y tú me estás dando un string, estás generando tu usuario un error a tiempo de ejecución, no en tiempo de compilación. 00:03:19
En compilación no había error porque tú leías un int, pero como ahora tú has dicho léete un int y me has dado un string, pues ahí hay un problema. 00:03:35
Java reacciona a este tipo de errores 00:03:42
a errores que digamos se ejecutan 00:03:46
o sea, se salen cuando hay una ejecución 00:03:49
con dos grandes categorías 00:03:53
los errores y las excepciones 00:03:56
los errores son chungos 00:03:59
los errores es 00:04:02
cuidado que aquí ha pasado algo 00:04:04
demasiado grande 00:04:07
aquí la java virtual machine 00:04:10
ha colapsado 00:04:13
no puedes hacer nada para recuperar 00:04:14
error 00:04:17
o una excepción 00:04:19
aquí ha pasado algo 00:04:22
que no me esperaba 00:04:25
normalmente el programa funciona 00:04:26
en este caso excepcional 00:04:29
pues no ha funcionado 00:04:31
las excepciones 00:04:32
se pueden 00:04:36
recuperar, o sea, tú puedes decir 00:04:37
vale, muy bien, si pasa 00:04:39
algo así, no 00:04:41
no colapses 00:04:43
déjamela a mí 00:04:45
y yo te digo cómo recuperarte 00:04:47
de este posible 00:04:49
error 00:04:50
¿se entiende más o menos? 00:04:52
¿sí? 00:04:55
entonces, una excepción es un error 00:04:56
un fallo en un programa que ocurre 00:04:59
en tiempo de ejecución 00:05:01
no saltará nunca una excepción 00:05:02
mientras estás compilando, mientras estás aplicando 00:05:05
códigos, cuando le das al play 00:05:07
Paso al play, llego a un array, intento leer la primera posición del array, 00:05:09
el array es null, y por lo tanto me da una null pointer exception. 00:05:14
Tú me dices, dame un número, yo te escribo gato, por lo tanto no es un número, 00:05:20
te lanzo un arithmetic number exception o una number format exception, no me acuerdo cómo sea. 00:05:25
¿Sí? 00:05:32
¿Qué cosa podrías decir? 00:05:33
Cuando un error ocurre, lo más normal es que se detenga el programa. 00:05:34
Nosotros hemos visto que hasta ahora sale un mensaje en rojo. 00:05:39
¿Por qué sale en rojo? 00:05:42
Porque en vez que en system.out.println, escribe en system.er.println. 00:05:46
Si vosotros en cualquiera de vuestros programas, en vez de system.out ponéis en system.er, el mensaje sale en rojo. 00:05:54
Vosotros tenéis dos canales de salida y un canal de entrada en cada programa. 00:06:01
¿vale? el canal del programa 00:06:05
de entrada es el system in 00:06:07
y el sistema out 00:06:09
es la salida 00:06:16
estándar 00:06:19
de tu programa 00:06:20
pero además tu programa, tu proceso 00:06:21
siempre tiene un tercer canal de salida 00:06:23
o sea, un segundo canal de salida 00:06:26
o un tercer canal de comunicación 00:06:28
que es el canal por donde 00:06:29
mandas los errores 00:06:32
¿vale? porque normalmente tú quieres decir 00:06:33
una cosa al usuario que te está usando 00:06:36
y una cosa distinta al programador que te ha programado por si pasa algo, ¿sí? 00:06:37
Es el concepto de que tú, si te llama tu cliente y te dice, 00:06:44
oye, me está dando este error de aquí, pues tú vas allí y te vas a mirar 00:06:48
el canal secreto de administradores y vas a mirar qué te ha dicho en el error, 00:06:53
porque al usuario le dirá, no me puedo conectar, 00:06:58
pero tú por debajo te habrías escrito, no me puedo conectar por esta razón de aquí, 00:07:04
porque el IP no funciona 00:07:07
porque no he podido generar no sé qué fichero 00:07:09
y cosas por el estilo. Entonces tú 00:07:11
entiendes esa jerga, entonces lo pones 00:07:13
allí, el otro no. Se pueden 00:07:15
redireccionar estos canales 00:07:17
para que escriban en ficheros. 00:07:19
Que es lo que se suele hacer, los famosos 00:07:21
ficheros de Londres. Entonces 00:07:23
los errores y los problemas se 00:07:25
escriben dentro de un fichero 00:07:27
conectado al system.er 00:07:29
para que escriba en estos ficheros 00:07:31
y entonces tú como 00:07:34
administrador, cuando hay un programa 00:07:35
que no funciona, vas a mirar los ficheros 00:07:37
de log de error, y allí te encuentras 00:07:39
cuáles son los problemas. 00:07:42
¿Dudas? 00:07:44
¿Con lo que has dicho entonces 00:07:46
por la tercera salida 00:07:47
podríamos crear nuestros propios 00:07:50
errores para el futuro? 00:07:52
No exactamente. Sí puedes hacer 00:07:55
lo que acabas de decir, de otra forma. 00:07:57
Eso es simplemente que tú puedes escribir 00:07:59
mensajes, digamos, 00:08:01
en dos canales. 00:08:02
Uno es el canal orientado 00:08:04
a hablar con quien te está usando, 00:08:06
y otro es el es el canal donde tú vas a meter los errores vale en eclipse o en básico lo que 00:08:08
hacen es escribir en el mismo sitio la consola pero luego se pueden redireccionar para que 00:08:17
escriban en un fichero para que escriban en un socket y lo mande por internet entonces 00:08:25
tú te recibes en tu ordenador hoy mira había un error en este sistema o cosa por estilo se puede 00:08:31
cambia la cosa 00:08:36
entonces tú tienes esas dos cosas 00:08:39
una es los mensajes normales 00:08:41
que te esperas, que hablas con el 00:08:43
usuario, con quien te está usando 00:08:45
y otro, que puedes usar o no 00:08:47
para los errores 00:08:49
pero esto es un poquito distinto 00:08:50
tú puedes crearte tus propios errores 00:08:53
pero con muchas excepciones 00:08:55
y lo veremos dentro de un rato 00:08:57
Java proporciona un mecanismo para controlar 00:09:00
situaciones que normalmente provocarían 00:09:03
una interrupción de ejecución, ¿vale? 00:09:05
Cuando vosotros, cuando yo digo 00:09:07
que explota el programa, que separa 00:09:09
la Java Vector Machine, es porque ha habido 00:09:11
uno de estos errores, de estas excepciones, 00:09:13
y nadie ha 00:09:16
controlado esta excepción. 00:09:17
Si esta excepción escala, escala, 00:09:19
escala, y llega al main, 00:09:21
y nadie en el main dice, mira, 00:09:23
cuando te pasa esto, tienes que solucionarlo 00:09:25
de esta forma, pues la única cosa 00:09:27
que puede hacer él es, oye, mira, lo siento 00:09:29
mucho, aquí se acaba. 00:09:31
Si tú dices, oye, soy un escáner, 00:09:33
léete un número, ¿vale? 00:09:35
Tú lees un número y te dan en vez de un string 00:09:37
y tú no le has explicado al programa 00:09:39
qué hacer cuando te dan un string, 00:09:42
pues lo único que se puede hacer 00:09:44
es parar la llave de tu máquina y decir, 00:09:46
tío, de aquí no puedo seguir. 00:09:47
Pero, sin embargo, si tú allí haces 00:09:50
lo que tienes que hacer para decirle 00:09:53
cuando te pase una cosa que no es un número, 00:09:54
tú le tienes que decir, oye, 00:09:58
te he pedido un número, no otra cosa, 00:10:00
y volver a pedírselo, pues entonces 00:10:01
él ya no explota. Él se mantendrá allí, 00:10:04
controlará la excepción y volverá a pedirte el mundo. 00:10:08
Pero eso tienes que decir tú. 00:10:11
Para manejar los errores, lo hemos dicho ya 00:10:13
en episodios anteriores, hay dos 00:10:21
formas, ¿vale? Una es la forma pesimista 00:10:23
y otra la forma optimista, digamos así. 00:10:26
La forma pesimista es, oye, mira, 00:10:29
yo sé que va a haber errores, va a haber 00:10:32
cosas problemáticas. 00:10:35
Pues voy a rellenar mi código 00:10:37
de comprobaciones 00:10:40
de ifs 00:10:42
para minimizar 00:10:43
la posibilidad que haya un error. 00:10:45
Entonces, 00:10:49
si mi programa explotaría 00:10:49
al meterle un número negativo, 00:10:52
yo voy a comprobar, oye, si el número 00:10:53
es negativo, no hagas nada. 00:10:55
Y si es positivo, sigue adelante. 00:10:57
Y si tú me tenías que dar un string, 00:11:00
voy a comprobar que sea un string. 00:11:02
Y si el string es null, pues me paro. 00:11:03
Si no, todo es cuniz. 00:11:05
El problema de este mecanismo 00:11:08
es que primero encontrar todos los posibles fallos 00:11:10
es complejo. 00:11:15
A lo mejor un caso concreto no se te ha pasado por acá 00:11:18
y a lo mejor necesitarías una condición booleana gigantesca 00:11:21
para cubrir ese caso. 00:11:26
Y si los datos son correctos, 00:11:29
estoy sobrecargando el sistema 00:11:32
con los innecesarios. O sea, 00:11:34
por cada vez que yo ejecuto mi programa 00:11:36
que todo iría bien, 00:11:38
te piden un número y te dan un número 00:11:39
tenía que ser positivo y es positivo. 00:11:42
Tú estás preguntando, ¿ma es un número? 00:11:44
Así, entonces sigue adelante. 00:11:47
¿Ma es positivo? Sí, sigue adelante. 00:11:48
Estás haciendo comprobaciones innecesarias. 00:11:50
Si, en situaciones en las que 00:11:54
estadísticamente es 00:11:56
bastante improbable 00:11:58
que te pongan 00:11:59
Dados mal, por ejemplo, este es un sistema que utilizan otros informáticos y entonces 00:12:02
saben lo que tienen que hacer, pues tú estás gastando recursos para nada. 00:12:07
Entonces se contrapone al manejo de excepciones optimista. 00:12:13
¿Cómo es optimista? 00:12:19
Optimista es decir, pues tranquilo, todo irá bien, tú ejecútalo y trabaja, no va a pasar 00:12:22
nada. 00:12:29
la mayoría de las veces, no va a pasar 00:12:30
nada. ¡Qué bien! 00:12:32
Pero yo marco 00:12:35
algunos 00:12:37
trozos de código diciendo, ¡eh, mira! 00:12:38
Si cuando tú estás aquí, que tranquilo 00:12:41
que no va a pasar nada, pero si 00:12:43
en el caso aquí pasara 00:12:44
algo, te voy a dejar unas 00:12:46
instrucciones para intentar 00:12:48
recuperarte. Estas instrucciones 00:12:50
pueden pasar del 00:12:52
escribe un mensaje de error 00:12:53
y colapsa, a 00:12:56
escribe este mensaje en un fichero 00:12:58
y colapsa. Ah, oye, 00:13:00
no colapses y te explico 00:13:02
cómo recuperarte de este error. 00:13:04
¿Sí? Proteger 00:13:06
el código potencialmente peligroso 00:13:09
implica una estructura 00:13:11
try-catch. 00:13:14
Sostantialmente, prueba a hacer una cosa 00:13:15
y pilla los posibles errores. 00:13:17
¿Dudas? 00:13:22
entiendo las 00:13:25
dos opciones 00:13:26
y para mí personalmente 00:13:28
me parece un poco la optimista 00:13:31
pero no sé 00:13:33
cuál es la diferencia entre una y otra 00:13:35
entre el programa de manera optimista 00:13:37
y de manera pesimista, porque para mí personalmente 00:13:39
diría, joder, pues lo hago todo 00:13:41
de manera optimista y ya está 00:13:43
pero ¿qué tiene de malo? 00:13:45
a diferencia del otro 00:13:47
no hay ni bueno ni malo 00:13:50
¿vale? el concepto es que 00:13:53
en determinadas 00:13:55
circunstancias te compensa 00:13:57
usar uno, en determinadas 00:13:59
circunstancias te compensa hacer otro. 00:14:01
Esto no es gratis. 00:14:03
¿Vale? O sea, aquí 00:14:06
haces un cierto sobrecarga 00:14:07
cuando haces este código, 00:14:09
algo tiene que estar allí cuidando 00:14:11
de decir, oye, mira, que si pasa algo, 00:14:13
lo tengo que recuperar, no puede explotar sin nada. 00:14:15
¿Vale? Pero no es gratis. 00:14:17
Tampoco el IF es gratis. Preguntarse si esto 00:14:19
es así. Ahora, hay situaciones 00:14:21
en que una cosa la puedes hacer y la otra 00:14:23
no. 00:14:25
O al revés. Esto de leer un número y que en vez de leer un gato, no lo puedes considerar con un string. 00:14:27
Porque el error no te sale en lo he metido en una variable y ahora puedo comprobar esa variable. 00:14:37
El error te sale antes. Cuando tú intentas poner algo en una variable que puede contener Intel, estás poniendo un string. 00:14:43
Entonces, colapsa antes que tú puedas hacer un if sobre esa variable. 00:14:49
Entonces, ahí, por ejemplo, no puedes usar el if. 00:14:52
hay otras situaciones 00:14:54
en el que tú no quieres 00:14:57
gestionarlos con excepciones 00:14:59
o no tienes una excepción 00:15:01
válida para ese contexto 00:15:02
y entonces quieres comprobar 00:15:04
que lo que estás metiendo 00:15:07
los datos que estás metiendo sean correctos 00:15:09
a través de ETH 00:15:11
eso depende 00:15:12
un poco del proyecto y de 00:15:15
dónde estás, hay estos dos medios 00:15:16
el ETH 00:15:19
es asegurarse que antes de utilizar 00:15:20
los datos, los datos sean correctos 00:15:23
el try es intentarlo 00:15:24
y si va mal me recupero 00:15:27
del error, son dos enfoques 00:15:29
distintos, el try catch 00:15:31
se utiliza más 00:15:32
a nivel de cosas 00:15:34
que puedan lanzar excepciones en lo que 00:15:36
se tiene que utilizar 00:15:39
el otro, a lo mejor 00:15:39
hay algunas situaciones 00:15:43
que compensa 00:15:44
decir, los ejemplitos que hemos hecho nosotros 00:15:46
me tienes que dar un número positivo 00:15:49
pues vale, compruebo que el número 00:15:51
sea positivo porque si es negativo 00:15:53
quiero hacer una cosa distinta 00:15:54
considera que el try catch lo que hace es 00:15:56
si va mal 00:15:58
utilizar ese valor 00:16:00
pero allí ya algo ha ido 00:16:02
mal 00:16:05
si lo podía prevenir a lo mejor no lo ha sido 00:16:05
¿vale? 00:16:09
es sutil, se puede hacer 00:16:11
muchas veces se pueden hacer las dos cosas 00:16:12
hay veces como el ejemplo anterior que no 00:16:14
se puede hacer por ejemplo el list 00:16:17
y se tiene que hacer con try catch 00:16:18
casos concretos, una regla 00:16:20
concreta de cuándo es el uno o el otro, 00:16:24
no te la sabré yo. 00:16:26
¿Vale? 00:16:28
Tened en cuenta que 00:16:32
esto también a lo mejor lo entenderás 00:16:33
mejor en 10 años 00:16:36
después que has trabajado en una empresa. 00:16:37
¿Vale? Aquí la clave 00:16:40
es saber que hay las dos herramientas, 00:16:42
las dos posibilidades de hacer las cosas, 00:16:44
y llega un momento de una vida y dirás, oye, mira, 00:16:45
aquí esto encaja perfecto. 00:16:47
es que depende me explico tú imagínate que yo tengo un campo edad y yo no quiero poner una 00:16:48
edad negativa. Si alguien me dice edad menos 7, eso no es un error. El tráquecho no hace nada. 00:17:11
El tráquecho dice, perfecto, metele menos 7. Ahora, otra cosa es que después de la edad, 00:17:19
yo voy a hacer un cálculo que si el número es negativo, por ejemplo, voy a hacer una raíz 00:17:25
cuadrada o qué sé yo, y si el número es negativo, me da un error. Pues entonces allí sí que podría 00:17:31
tratarlo con un trackech. Pero el número ya está en la variable, no sé si me explico. 00:17:37
Entonces, ejemplo de pesimista contra optimista, ¿vale? Entonces, vosotros sabéis que si yo divido 00:17:42
un número por cero, explota. Aritmética excepción. No se puede dividir un número por cero, ¿vale? 00:18:01
entonces, pesimista 00:18:08
hay un main, tengo un scanner 00:18:10
digo, dame un entero, me dan 00:18:13
un entero y me pregunto 00:18:15
si el denominador es distinto 00:18:16
de cero, pues entonces 00:18:19
haz la operación, y si no 00:18:20
dices algo 00:18:22
aquí no hay un else, pero 00:18:24
sigues con la 00:18:26
programación, ¿vale? 00:18:28
aquí no explota 00:18:30
porque si el denominador es cero 00:18:32
no hará la operación, ¿vale? 00:18:34
No escribirá esta línea de códigos, pero no la ejecuta y por lo tanto no es nuestro, ¿vale? 00:18:36
Pero todas las veces que yo le pongo, como tengo en el nominador, un número que no es cero, 00:18:44
yo tendré que hacer este if, ¿vale? 00:18:50
Y que me dirá, sí, no es cero, y me escribirá la cosa. 00:18:53
Es como una operación esta. 00:18:56
Si yo sé que esto prácticamente no va a pasar nunca, o sea, a lo mejor es un gasto innecesario. 00:18:57
A nivel de 3K, yo no hago el if, simplemente hago esta división y pruebo a hacer esta división. 00:19:03
En el caso en que explote una excepción, lo que hago es escribir este número no es válido o recuperarme o cosas por el estilo. 00:19:13
Esto no hace explotar el programa, el programa sigue adelante. 00:19:20
Si yo quito 00:19:24
Este de aquí y pongo solo 00:19:26
Llave, llave, no hace nada 00:19:28
No escribe nada, no cambia nada y sigue adelante 00:19:30
Exactamente como hacía este 00:19:32
Ha habido un error 00:19:34
Pero se ha recuperado el error 00:19:37
Y sigue adelante 00:19:38
Esto porque hay alguien 00:19:39
Que se ha encargado de 00:19:42
Hacer este error, veis que estamos en el main 00:19:44
Pero el 00:19:46
El código que da problemas 00:19:48
Está protegido 00:19:50
Si yo quitar el track edge 00:19:51
cuando esto se ejecuta, da una excepción 00:19:53
no hay nadie 00:19:56
que gestiona, que controla esta excepción 00:19:57
estoy en el made, por lo tanto 00:20:00
la java esto machine se para 00:20:02
y me da un error de excepción 00:20:03
¿qué pasa con esto? 00:20:05
dudad, vale, existe una clase 00:20:07
que se llama exception, lo podéis encontrar en el 00:20:13
API, vale, exception es 00:20:15
una clase 00:20:17
de alto nivel 00:20:19
de las que heredan 00:20:21
la mayoría de los 00:20:23
de las clases que acaban con 00:20:25
bla bla bla excepción. Null pointer exception, aritmetic exception, stackable flow exception, etc. 00:20:27
No sé si era un exception, no lo recuerdo bien. Pero bueno. Cuando en este tema, la JVM crea un 00:20:35
objeto de la clase exception. O sea, cuando hay este tipo de error, que se ha estropeado, 00:20:44
la JVM va a recopilar datos su por qué ha habido este error y lo esguarda, crea un objeto 00:20:49
rellenando sus atributos, un objeto 00:20:56
de tipo excepción. ¿Vale? Este objeto. 00:20:59
Entonces, si yo dentro 00:21:06
del ramacatch, 00:21:07
dentro de esta variable, 00:21:09
tendré una referencia al objeto 00:21:11
excepción que ha creado la JavectorMachine. 00:21:13
Entonces, le podré preguntar, 00:21:16
mira qué ha pasado, dame una 00:21:17
descripción de por qué has explotado, 00:21:19
dame una descripción de lo que ha 00:21:21
pasado, de cuál es el contexto, 00:21:23
se puede hacer varias cosas sobre 00:21:25
la excepción. 00:21:27
En este objeto se guarda información sobre el error, quién lo ha producido, dónde se ha producido, qué ha causado errores, etc. 00:21:29
Un mismo código peligroso podría causar distintos tipos de excepciones. 00:21:38
Aquí podría ser que ponga un try, luego varias líneas de código y un catch. 00:21:43
Y puede ser que allí haya explotado por un null pointer exception, haya explotado por un number format exception, 00:21:47
haya explotado porque no ha podido leer un fichero, la IO exception, input output exception. 00:21:53
y podría ser que yo no lo sé 00:21:59
si lo pongo así 00:22:02
sea cual sea 00:22:03
el error, la excepción 00:22:07
que ha saltado, pues 00:22:10
llevo aquí 00:22:11
porque una null pointer exception 00:22:12
es una excepción 00:22:15
porque la he dado 00:22:18
la IO exception es una excepción 00:22:18
entonces aquí estoy pillando algo genérico 00:22:21
y sea cual sea el error 00:22:23
voy a ver que pasa 00:22:26
sin embargo 00:22:27
se puede manejar 00:22:29
las excepciones de una forma un poquito 00:22:33
más fina. O sea, decir que 00:22:34
oye, mira, si tú el error que ha habido 00:22:36
era un all pointer exception, 00:22:39
haz esto. Pero si 00:22:41
en vez de no era un all pointer exception, 00:22:42
era otro tipo de error, pues 00:22:44
haz una cosa distinta. 00:22:46
Y esto se hace 00:22:48
así. 00:22:50
Encontré 00:22:54
y luego digo, catch arithmetic 00:22:55
exception. Pues aquí dentro 00:22:58
este bloque 3 se ejecutará 00:23:00
si es sólo si la excepción 00:23:02
que ha explotado es una aritmética 00:23:04
exception. 00:23:06
Si no, se ejecutará esto 00:23:08
porque aquí dentro caen 00:23:10
todas las otras excepciones posibles. 00:23:12
¿Ve? 00:23:15
Tened en cuenta que el orden cuenta. 00:23:15
Si yo esto lo inverto, 00:23:18
la aritmética exception no la 00:23:20
ejecutaré nunca, porque siempre pillará 00:23:22
la primera como, ah, sí, es una excepción. 00:23:24
¿Entiendes? 00:23:28
¿Ve? 00:23:28
Entonces, en una situación como esta, yo estaría ejecutando el bloque 1, ¿vale? 00:23:32
Si no hay ninguna excepción, ejecuto el bloque 2 y luego voy al bloque 5. 00:23:36
Sin ningún problema. 00:23:43
Si salta una excepción de tipo aritmético, yo ejecutaría el bloque 1, 00:23:45
el bloque 2 lo ejecutaría parcialmente, asterisco, hasta donde salta el error. 00:23:49
Donde salta el error, entraría en el bloque 3. 00:23:55
Ejecutaría el bloque 3 y luego me iría al bloque 5. 00:23:58
Si en vez sale una excepción que no es una aritmética excepción, cualquier otra excepción, 00:24:02
pues bloque 1, bloque 2 a mitad, saltaría al bloque 4 y seguiría por bloque 4. 00:24:09
¿Dudas? 00:24:16
Existe también una cláusula opcional. 00:24:19
Esto es un try, catch, catch, catch, catch. 00:24:23
Se puede poner un finally. 00:24:26
el finales en cualquier caso después que has hecho lo que tiene que hacer ejecuta esta parte 00:24:28
como si fuera una parte que tanto que explote como que no así que la tiene que ejecutar pues 00:24:38
entonces la pongo en un final por ejemplo si no hay excepciones ejecuta la primera luego 00:24:44
ejecuta el bloque 2 entero, no ha habido excepciones, ejecuta el finally porque 00:24:57
esto se ejecuta siempre y luego va a ser bloque cíclico. 00:25:01
¿El finally sería como el default de un switch o el else to need? 00:25:06
No, porque tú estás ejecutando tanto el 2 como el 4, o ejecutas esto o ejecutas esto. 00:25:11
Finally es literalmente lo que dice, try, prueba a hacer esto, pilla estas excepciones 00:25:18
y al final hace esto. Entonces, si no hay excepciones, el bloque 1, bloque 2, bloque 00:25:25
finally y bloque 5. Ahora, si hay una excepción de tipo aritmético, entonces sería bloque 00:25:35
1, bloque 2 es donde hay la excepción, ejecutaría el bloque 3, después se ejecuta el finally 00:25:46
porque el final se ejecuta y después sigue con el fin. 00:25:53
Cualquier tipo de excepción diferente ejecutaría el bloque 1, 00:25:59
el bloque 2 a mitad y saltaría el final. 00:26:06
Porque no hay ningún catch que está pillando este tipo de excepciones, 00:26:10
pero el final se ejecuta de verdad. 00:26:14
Tened en cuenta que como no se ha pillado el catch, 00:26:16
el bloque 5 no llega. 00:26:20
Se ejecuta el 4 y se ha cerrado. 00:26:22
Entonces, ¿qué hay en la clase Exception? 00:26:26
La clase Exception tiene varias cosas, tiene varios parámetros, etcétera, etcétera, que hay útil. 00:26:38
Hay un getMessage que devuelve un string, que es una descripción de por qué ha ocurrido el error. 00:26:46
Entonces, yo desde dentro si uso e.getMessage sabré por qué ha explotado, ¿vale? 00:26:54
Uso e porque la excepción se llama e. 00:27:05
Si uso, si estoy aquí, debería hacer ae.getMessage, ¿sí? 00:27:07
ToString, algo parecido, ¿vale? 00:27:15
Porque el getMessage te da solo el mensaje de error, 00:27:19
el toString te da una representación del objeto entero. 00:27:23
Entonces incluye el mensaje de error, 00:27:27
pero te da también qué clase es, etc. 00:27:29
ReceptionString es el constructor de la clase, ¿vale? 00:27:34
Sirve porque tú puedes crear una excepción tuya. 00:27:36
PrintStackTrace es lo que veis cuando ha habido uno de estos errores, 00:27:42
que salen todos los métodos que estaban 00:27:47
llamando. Este es un error 00:27:50
que ha pasado en este método, que había sido 00:27:52
llamado desde este método, que había sido llamado 00:27:54
desde este método, que había sido llamado 00:27:55
este. Es 00:27:57
imprime una traza, 00:27:58
una descripción 00:28:02
de la pila de llamadas 00:28:04
de métodos. 00:28:06
Esta es la misma stack de los stack overflow. 00:28:09
Hasta aquí 00:28:17
control de excepciones, ¿vale? 00:28:18
Entonces, relativamente sencillo, 00:28:22
existen 00:28:23
métodos por ahí 00:28:24
que si funcionan mal 00:28:28
pueden lanzar una excepción 00:28:30
y que tú tienes que 00:28:31
controlar con 00:28:34
un try-catch, ¿vale? 00:28:36
Entonces, existen excepciones 00:28:37
que puedes 00:28:40
controlar o no. 00:28:42
Por ejemplo, la null pointer exception. 00:28:44
Si tú la controlas bien, 00:28:46
si tú no la controlas, te arriesga 00:28:48
pero hay a tú 00:28:50
¿vale? existen 00:28:52
excepciones en vez que si tú 00:28:54
tienes un método que lanza esa excepción 00:28:56
y no has hecho un try catch 00:28:58
el mismo compilador te avisa 00:29:00
te dice no, este método aquí no lo puedes 00:29:02
llamar si no lo pones dentro del try catch 00:29:04
¿vale? ahora veremos 00:29:06
de un tipo y cuáles son 00:29:08
¿vale? 00:29:10
pero técnicamente tú puedes hacer 00:29:12
puedes capturar 00:29:14
las excepciones, pero puedes hacer 00:29:16
métodos que lanzan 00:29:18
una excepción. Tú puedes 00:29:20
hacer que a un determinado momento, 00:29:22
mientras estás trabajando, dices, y si llegas aquí 00:29:24
y las condiciones son estas, 00:29:26
pues para 00:29:29
la ejecución y lanza 00:29:30
una excepción. Porque hemos llegado a un 00:29:32
punto en que no puedo seguir adelante. 00:29:34
¿Vale? Es como un 00:29:37
punto de bloqueo de, oye, yo 00:29:38
desde aquí no puedo seguir, a menos 00:29:40
que alguien nos recoja esta 00:29:41
excepción y me diga cómo hacerlo, 00:29:43
yo aquí ha acabado no tengo los datos para seguir adelante para lanzar una 00:29:46
excepción se usa el comando true lanza y la excepción que quiero lanzar 00:29:53
no puedo crear una new excepción excepción e igual new excepción le pongo 00:30:00
dentro el mensaje que quiero que ponga y luego la lanzo 00:30:04
el objeto que se le pasa a true tiene que ser de la clase excepción o una 00:30:11
cualquier subclase que la extienda incluso excepciones personales que os podéis crear 00:30:15
vosotros puedes crear la clase mi excepción que extends exception y luego hacer mi excepción 00:30:20
e es igual a new mi excepción y a ese punto throw e luego hacemos pruebas 00:30:27
que hace el throw sale inmediatamente del bloque del código actual cuando encuentro un throw he 00:30:38
acabado, allí voy a mi padre, a quien me ha llamado. Si allí dentro tenemos, estaba en un 00:30:44
try-catch y tengo un catch asociado a la excepción que he lanzado, pues entonces se recupera y se 00:30:51
hace ese código. Si no, salgo de ese bloque también y me voy a quien me había llamado. O sea, se va 00:31:02
para arriba si yo tengo el método busca que hace el error y el método busca lo había llamado el 00:31:13
método haz algo vale entonces yo voy a mirar si haz algo tiene un try catch o no si no lo tiene 00:31:19
va al que lo había llamado y si no lo tiene va al que lo había llamado hasta llegar al main si ninguno 00:31:26
ha hecho un try-catch nunca, pues allá es cuando bloqueo la JVM y se ha acabado totalmente. 00:31:33
Si en cualquiera de las stack de la pila de llamadas uno ha puesto un try-catch, 00:31:43
pues eso es el que recupera, o sea, que captura la excepción y a ver qué me dice. 00:31:49
proceso continuo está llegado al método main 00:31:57
si nadie lo ha hecho, pues es fatal 00:32:02
esta otra cláusula 00:32:04
que no es trow 00:32:09
es trow 00:32:10
con la s de tercera persona 00:32:11
en inglés 00:32:15
se usa 00:32:17
en las declaraciones de los métodos 00:32:19
para decir que 00:32:21
avisar 00:32:23
que oye, quien use este método f 00:32:24
que sepas 00:32:27
que este método puede lanzar 00:32:29
un determinado tipo de excepción. 00:32:31
Entonces, 00:32:35
cuando yo voy a usar el método F, 00:32:35
sé que al usarlo 00:32:37
debería meterlo 00:32:39
dentro de un try-catch 00:32:41
que recupere este tipo de excepción. 00:32:42
Esto lo veremos que algunos métodos 00:32:47
cuando vamos en el API, me dice 00:32:49
este método, throws, no sé qué. 00:32:51
Entonces, cuando yo lo lanzo, tengo que comprobar 00:32:53
que este método 00:32:55
esté bien. Lo veremos por ejemplo 00:32:56
en los ficheros, en la gestión de ficheros 00:33:00
todas las IOException 00:33:03
necesitan ser tratadas de esta forma. 00:33:05
Si un método lanza más de una excepción 00:33:09
se indicará detrás de TROs. O sea, TROs de 1 00:33:11
con MET2, con MET3, con MET4. 00:33:14
Para no que utilicemos métodos que lanzan por detrás de excepciones 00:33:25
o lo protegemos o no lo protegemos. Esto lo hemos dicho ya 00:33:29
sustancialmente, pero luego lo vemos en la práctica. 00:33:32
La última cosa que me interesa, sustancialmente, porque luego están las 00:33:37
excepciones personalizadas, que a lo mejor lo vemos en otro día así, 00:33:41
es la jerarquía de excepciones. Todas las excepciones son throwable, o sea, se 00:33:45
pueden lanzar, pero dentro de throwable hay dos tipos, hay los errores o las excepciones, 00:33:50
lo que decimos al principio 00:33:57
los errores son errores graves 00:33:59
de allí no te recuperas, es un problema 00:34:01
interno de la JavaScript Machine 00:34:03
ha acabado la memoria, pues si ha acabado la memoria 00:34:04
no puedes hacer nada 00:34:07
también porque la rama está muy cara 00:34:08
¿sí? entonces estos son 00:34:11
los que son bla bla bla error 00:34:13
bla bla bla error 00:34:15
¿sí? 00:34:16
mientras que las excepciones son errores 00:34:19
manejables o recuperables, esto algo 00:34:21
puede hacer, puede hacer un try catch para 00:34:23
intentar solucionar el problema 00:34:25
Y aquí dentro hay dos tipos. 00:34:27
Hay la RuntimeException y las otras. 00:34:30
Si soy RuntimeException, son errores que pueden pasar, 00:34:35
pero que son tan habituales, son tan comunes, 00:34:40
que no hace... 00:34:46
O sea, que tú puedes decidir de poner un trackecho o no. 00:34:48
Por ejemplo, el NullPointerException. 00:34:53
Null pointer exception es muy común 00:34:55
Si tú dijeras, oye no 00:34:58
Lo tienes que, siempre que 00:35:00
Hay la posibilidad de un null pointer exception 00:35:02
Tienes que hacer algo 00:35:04
Pues mi código estaría lleno de try-catch 00:35:04
Porque cualquier cosa que tú utilices 00:35:07
Cualquier objeto podría ser null 00:35:09
¿Sí? 00:35:10
Entonces se te rellenaría todo de try-catch 00:35:13
Entonces ellos dicen, vale, no 00:35:15
La null pointer exception 00:35:17
Es una runtime exception 00:35:19
Y la runtime exception 00:35:21
puedes decidir de no 00:35:23
no capturarlas 00:35:25
de dejarlas sin trigger 00:35:28
sin embargo 00:35:29
las que no son runtime exception 00:35:32
pues sí que tienen que ser 00:35:34
capturadas siempre 00:35:37
y son las que decía antes 00:35:37
si aquí como por ejemplo 00:35:39
aquí son ejemplos que no veremos nunca 00:35:41
si tú intentas hacer un método 00:35:44
que lanza una de estas 00:35:46
excepciones de aquí 00:35:48
no te permite el compilador 00:35:49
de compilar el código si tú no lo has 00:35:52
puesto dentro del tránsito. 00:35:54
Esto es un poco la estructura 00:36:00
de lo que hay por aquí. Todos son 00:36:02
trouble. Aquí están los errores, como por 00:36:04
ejemplo una virtual machine error 00:36:06
que aquí hereda 00:36:08
el out of memory error. No tengo 00:36:10
memoria, no puedo ejecutar. 00:36:12
El, no lo sé, stack 00:36:14
overflow error. 00:36:16
Y si no están las 00:36:19
excepciones, de aquí están la 00:36:20
runtime exception, que son las que 00:36:22
pueden ser no controlables 00:36:24
y todas las otras excepciones. 00:36:26
¿Sí? Estas 00:36:29
hay que controlarlas siempre, 00:36:30
como por ejemplo todas las 00:36:33
IOException, por eso cuando veremos 00:36:34
ficheros, pues estaremos siempre con 00:36:36
try-catch. 00:36:38
Estas en vez de son las que, oye, 00:36:40
mira, por ejemplo, array index 00:36:42
autobound. Nosotros 00:36:44
no hemos usado nunca try-catch, 00:36:46
pero sí hemos usado los 00:36:48
arrays, y podría ser que 00:36:50
habríamos podido acceder 00:36:52
fuera. De hecho, algunos ejercicios 00:36:54
os han dado ese error. 00:36:56
Pero no te esfuerza a 00:36:58
crearlo porque si no, deberías 00:37:00
estar todo dentro de lo que has hecho constantemente. 00:37:02
¿Vale? Entonces, estos errores aquí 00:37:04
son errores muy comunes 00:37:06
que pero te dicen, oye, mira, si quieres lo haces 00:37:07
y no, no. 00:37:10
¿Sí? 00:37:11
Y excepciones personalizadas me puedo crear 00:37:13
mis propias excepciones 00:37:16
y luego lanzarlas. 00:37:17
¿Vale? 00:37:21
miramos esto para entender 00:37:21
imaginaos, aquí me estoy creando 00:37:24
una divide by 0 exception 00:37:26
que estende una aritmética exception 00:37:28
esta es una clase mía 00:37:30
hago lo que tengo que hacer aquí dentro 00:37:32
y aquí tengo un método 00:37:34
el método dividir que pilla dos números 00:37:36
y que puede lanzar 00:37:39
la divide by 0 exception 00:37:41
lo estoy avisando 00:37:42
entonces, quien use 00:37:45
dividir con dos valores, debería 00:37:46
ponerlo dentro de un try catch porque podría 00:37:48
saltarla divideByZeroException, ¿entiendes? 00:37:50
Pero como la divideByZeroException 00:37:55
extiende la ArithmeticException 00:37:59
y la ArithmeticException es una RuntimeException, 00:38:01
por si no uso el Tracker, no me dice nada. 00:38:06
¿Sí? Vale. Y con esto, 00:38:11
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:
5
Fecha:
30 de enero de 2026 - 13:48
Visibilidad:
Clave
Centro:
IES ROSA CHACEL
Duración:
38′ 20″
Relación de aspecto:
1.78:1
Resolución:
1920x1080 píxeles
Tamaño:
321.67 MBytes

Del mismo autor…

Ver más del mismo autor

EducaMadrid, Plataforma Educativa de la Comunidad de Madrid

Plataforma Educativa EducaMadrid