1
00:00:10,630 --> 00:00:17,070
Hola desde luego nuevamente Ubaldo Acosta espero que estén listos para comenzar con esta elección.

2
00:00:17,080 --> 00:00:22,490
A continuación vamos a ver más respecto al tema decepciones en Java están listos.

3
00:00:22,600 --> 00:00:32,760
Vamos la cláusula throws en esta elección vamos a continuar revisando más temas acerca de las excepciones

4
00:00:32,820 --> 00:00:33,970
en Java.

5
00:00:34,170 --> 00:00:39,870
Vamos a hablar ahora de la cláusula throws la cual nos permite especificar el tipo de decepción que

6
00:00:39,870 --> 00:00:41,700
arroja cierto método.

7
00:00:41,700 --> 00:00:47,400
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

8
00:00:47,400 --> 00:00:48,560
que lo manda llamar.

9
00:00:48,750 --> 00:00:52,080
Una excepción que extiende Deception.

10
00:00:52,110 --> 00:00:58,380
Si estamos obligados a declararla en la firma del método ya que ese tipo de excepciones al igual que

11
00:00:58,380 --> 00:01:04,530
cuando comentábamos que se deben procesar por un bloque y coach si no son procesadas por este bloque

12
00:01:04,800 --> 00:01:11,070
entonces estamos obligados a declararlas dentro del método donde se hace uso del método que arroja la

13
00:01:11,070 --> 00:01:14,540
excepción una excepción que extiende de runtime exception.

14
00:01:14,580 --> 00:01:21,170
No estamos obligados a declararla en la firma del método al usar un método que arroje ese tipo de excepciones

15
00:01:23,990 --> 00:01:33,200
la cláusula Zou vamos a revisar ahora la cláusula drow esta palabra reservada nos permite lanzar explícitamente

16
00:01:33,260 --> 00:01:40,250
una excepción por ejemplo podemos utilizar una clase de excepción que viene de la clase exception o

17
00:01:40,250 --> 00:01:46,100
cualquier otra clase de tipo acepción y en conjunto con el operador Niu crear un nuevo objeto de esta

18
00:01:46,100 --> 00:01:52,760
clase y así arrojar una excepción de manera explícita en el código podemos observar como dentro del

19
00:01:52,760 --> 00:02:00,080
método X se lanza una nueva excepción del tipo exception utilizando la palabra reservada Zou seguida

20
00:02:00,080 --> 00:02:03,990
de la clase de tipo exception que queremos instancias.

21
00:02:04,790 --> 00:02:10,940
Normalmente las clases de excepción en su constructor tienen una cadena que será el mensaje que se mandará

22
00:02:11,000 --> 00:02:16,130
al esta actriz al momento en que ocurra el problema o se lance la excepción.

23
00:02:16,130 --> 00:02:22,250
Posteriormente lo que observamos es que el método main al hacer uso del método X obliga a procesar la

24
00:02:22,250 --> 00:02:29,960
excepción por medio de un bloque Reixach o a declarar en la firma del método que el método X puede llegar

25
00:02:30,020 --> 00:02:32,680
a lanzar la excepción de tipo exception.

26
00:02:33,080 --> 00:02:38,440
Y esto lo veremos en la firma del método por medio de la palabra throws exception.

27
00:02:38,630 --> 00:02:45,200
De hecho con un proceso similar es como nuestra aplicación puede convertir excepciones de tipo exception

28
00:02:45,770 --> 00:02:53,830
es decir cheat excepciones a excepciones de tipo runtime exception es decir un check exception crearon

29
00:02:53,850 --> 00:02:59,960
nuestras propias clases de tipo runtime reception y al momento de envolver una excepción de tipo exception

30
00:03:00,170 --> 00:03:05,470
con un bloque 30h se puede relanzar una excepción de tipo runtime section.

31
00:03:05,480 --> 00:03:12,200
De esta manera no obligamos a los métodos que utilicen nuestros métodos a que declaren el tipo de excepción

32
00:03:12,380 --> 00:03:20,110
que se puede arrojar ya que se han convertido a tipo runtime exception creación de nuestras propias

33
00:03:20,110 --> 00:03:21,040
clases excepción

34
00:03:23,900 --> 00:03:29,270
vamos a ver a continuación cómo podemos crear nuestras propias clases de recepción las cuales pueden

35
00:03:29,270 --> 00:03:36,280
extender la clase exception Orueta y reception o incluso extender de alguna clase de decepción que nosotros

36
00:03:36,290 --> 00:03:42,720
hayamos definido la intención de crear nuestras propias clases decepción es personalizar los mensajes

37
00:03:42,720 --> 00:03:49,380
de error que se envían al usuario por ejemplo un error de base de datos se puede atrapar y convertir

38
00:03:49,650 --> 00:03:56,300
en un mensaje de error legible al usuario que usa nuestra aplicación o como hemos comentado anteriormente.

39
00:03:56,400 --> 00:04:02,190
Podemos crear clases de excepción que desciendan de la clase runtime exception para no obligar a los

40
00:04:02,190 --> 00:04:09,210
usuarios a usar bloques y catch o declarar en la firma de los métodos el tipo de decepción que arrojará.

41
00:04:09,210 --> 00:04:15,280
En caso de que suceda alguna excepción del tipo que hemos declarado como hemos observado en el código

42
00:04:15,520 --> 00:04:21,980
estamos creando una clase de tipo ni excepción la cual hereda de la clase exception.

43
00:04:22,060 --> 00:04:28,120
Sin embargo puede extender de cualquier otra clase de excepción que nos interese posteriormente.

44
00:04:28,120 --> 00:04:34,900
Esta clase contiene un constructor el cual recibe el mensaje que nos servirá para inicializar el atributo

45
00:04:34,990 --> 00:04:41,560
mensaje de la clase padre mandando a llamar el constructor Padre por medio de la palabra super y con

46
00:04:41,560 --> 00:04:48,330
esto queda inicializar a nuestra clase de tipo exception posteriormente en la clase arrojar excepción

47
00:04:48,330 --> 00:04:55,440
dos podemos observar que si lanzamos una excepción de tipo ni excepción y como es de tipo exception

48
00:04:55,710 --> 00:05:02,730
se obliga al método X a declarar en su firma el tipo de acepción que se lanzará en caso de error.

49
00:05:02,730 --> 00:05:08,520
Así es como crearemos nuestras propias clases de excepción y así también es como las usaremos dentro

50
00:05:08,520 --> 00:05:09,600
de nuestro código IAVA

51
00:05:13,650 --> 00:05:15,720
uso de excepciones utilizando herencia

52
00:05:18,440 --> 00:05:24,830
vamos a revisar ahora el tema de uso de excepciones utilizando herencia en el código mostrado vemos

53
00:05:24,830 --> 00:05:30,400
dos clases una llamada mi excepción la cual extiende de la clase exception.

54
00:05:30,530 --> 00:05:37,340
Posteriormente declaramos una clase llamada Mi acepción hija la cual es una subclase de mi acepción

55
00:05:38,000 --> 00:05:42,990
por lo tanto tenemos una jerarquía de clases de excepciones que hemos creado.

56
00:05:43,040 --> 00:05:49,910
Por otro lado en la clase arrojar excepción 3 se arroja una subclase llamada Mi acepción hija dentro

57
00:05:49,910 --> 00:05:56,540
del método X pero si observamos la firma del método el método declara que se arroja una excepción que

58
00:05:56,540 --> 00:06:00,030
es una superclase llamada ni acepción.

59
00:06:00,230 --> 00:06:06,080
La intención de hacer esto es que el método internamente puede arrojar excepciones que son subclases

60
00:06:06,530 --> 00:06:13,250
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

61
00:06:13,250 --> 00:06:19,370
rango más amplio para el manejo de excepciones utilizando precisamente el concepto de herencia pero

62
00:06:19,370 --> 00:06:26,700
ahora dentro de la definición de clases de tipo exception y al igual que cuando trabajamos con polimorfismo

63
00:06:26,960 --> 00:06:32,670
mucho del código en cualquier lenguaje de programación y también en el lenguaje Java es crear métodos

64
00:06:32,820 --> 00:06:38,790
lo más genérico posibles que nos ayuden a englobar más posibilidades de excepción en menos líneas de

65
00:06:38,790 --> 00:06:45,410
código que al final nos ahorrará costos de mantenimiento en nuestras aplicaciones al tener código lo

66
00:06:45,420 --> 00:06:47,430
más genérico y compacto posible

67
00:06:52,000 --> 00:06:54,400
uso de excepciones en la sobrecarga de métodos

68
00:06:57,030 --> 00:07:02,370
vamos a ver a continuación el uso de excepciones al momento de sobrecargar nuestros métodos en Java.

69
00:07:02,550 --> 00:07:08,790
Algunas de las reglas que debemos respetar son un método que describe a un método padre que declara

70
00:07:08,880 --> 00:07:16,410
una excepción puede hacer lo siguiente No arrojar ninguna excepción es decir omitir la excepción en

71
00:07:16,410 --> 00:07:17,620
su firma.

72
00:07:17,850 --> 00:07:25,890
Arrojar una o más excepciones arrojadas por el método padre arrojar una o más excepciones que son subclases

73
00:07:26,100 --> 00:07:33,600
de la acepción arrojada un método que describe a un método padre que declara una excepción no puede

74
00:07:34,230 --> 00:07:38,630
arrojar excepciones adicionales no arrojadas en el método padre.

75
00:07:39,030 --> 00:07:45,630
Arrojar superclase es de las excepciones arrojadas por el método padre en el código mostrado.

76
00:07:45,630 --> 00:07:55,620
Observamos una clase padre arrojar excepcional y dos clases hijas arrojar XB y arrojar XC las cuales

77
00:07:55,950 --> 00:08:03,760
describen el método X definido por la clase padre lo que estamos aclarando en este código son las excepciones

78
00:08:03,760 --> 00:08:09,380
que podemos utilizar en la firma de los métodos sobre escritos por las clases hijas.

79
00:08:09,400 --> 00:08:16,570
Por un lado observamos que la clase arrojar XB en la firma del método x en lugar de utilizar la misma

80
00:08:16,570 --> 00:08:24,190
excepción que en la firma del método de la clase padre ni excepción se utiliza una subclase ni acepción

81
00:08:24,190 --> 00:08:24,820
hija.

82
00:08:25,090 --> 00:08:31,330
De esta manera es claro que no necesariamente debemos utilizar la misma clase decepción en la firma

83
00:08:31,330 --> 00:08:38,020
del método sino que puede ser alguna otra clase dentro de la jerarquía de clases de excepción que estamos

84
00:08:38,020 --> 00:08:43,150
utilizando siendo siempre subclases y no súper clases.

85
00:08:43,360 --> 00:08:51,160
Por otro lado observamos en la clase arrojar XP que se utiliza precisamente una súper clase exception

86
00:08:51,730 --> 00:08:59,410
de la clase excepción utilizada en la clase padre ni excepción y por lo tanto esto no es válido y existe

87
00:08:59,470 --> 00:09:02,290
un problema de compilación en nuestro código.

88
00:09:02,320 --> 00:09:07,480
Más adelante veremos un ejemplo de ese tipo de manejo de excepciones en la firma de los métodos que

89
00:09:07,480 --> 00:09:07,600
se.
