V1 Contenidos Unidad 1 Semana 5

TALLER DE PROGRAMACIÓN.
NET
PROGRAMACIÓN EN .NET
ESCUELA DE CONSTRUCCIÓN E INGENIERÍA
Director de Escuela / Marcelo Lucero
ELABORACIÓN
Experto disciplinar / Cristián Molina
Diseñador instruccional / Evelyn Aguilera
VALIDACIÓN PEDAGÓGICA
Jefa de diseño instruccional y multimedia / Alejandra San Juan Reyes
Experto disciplinar / Carlos Garcés
DISEÑO DOCUMENTO
Didactic
Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 2

Contenido
APRENDIZAJE ESPERADO DE LA SEMANA: ...................................................................... 4
1. DIFERENCIA LOS COMPONENTES BASE EN EL DESARROLLO DE UNA
CLASE CON PROGRAMACIÓN ORIENTADA A OBJETOS (POO) ....................... 4
1.1. PROGRAMACIÓN ORIENTADA A OBJETOS ......................................................... 4
1.1.1. INTRODUCCIÓN ....................................................................................................... 5
1.1.2. ORIGEN ..................................................................................................................... 5
1.2. CONCEPTOS FUNDAMENTALES ........................................................................... 6
1.3. CARACTERÍSTICAS DE LA POO ............................................................................ 7
EJEMPLIFICACIÓN ................................................................................................................. 9
1.4. LANZAMIENTO DE EXCEPTION ............................................................................. 9
1.4.1. TIPOS DE ERRORES ............................................................................................. 13
1.4.2. MANEJO DE LO INESPERADO ............................................................................. 13
1.5. CONTROL NO ESTRUCTURADO DE EXCEPCIONES ........................................ 20
1.5.1. ON ERROR GOTO LINE......................................................................................... 20
1.5.2. ON ERROR RESUME NEXT .................................................................................. 21
1.5.3. ON ERROR GOTO 0 ............................................................................................... 22
1.5.4. ON ERROR GOTO -1 ............................................................................................. 22
1.6. JERARQUÍA DE EXCEPCIONES DEL MOTOR DE TIEMPO DE EJECUCIÓN .. 23
1.7. CONCEPTO DE EXCEPCIÓN ................................................................................ 25
1.7.1. LA CLASE SYSTEM.EXCEPTION.......................................................................... 26
1.7.2. EXCEPCIONES PREDEFINIDAS COMUNES ....................................................... 26
1.7.3. LANZAMIENTO DE EXCEPCIONES. INSTRUCCIÓN THROW ........................... 27
1.7.4. CAPTURA DE EXCEPCIONES. INSTRUCCIÓN TRY .......................................... 27
1.8. BLOQUES................................................................................................................ 30
EJEMPLIFICACIÓN ............................................................................................................... 33
1.9. EXCEPCIONES - MÚLTIPLES CATCH PARA UN TRY ........................................ 33
1.10. EXCEPCIONES - CLASE PADRE EXCEPTION .................................................... 33
1.11. EXCEPCIONES - BLOQUE FINALLY .................................................................... 35
1.12. EXCEPCIONES - LANZAR UNA EXCEPCIÓN MEDIANTE COMANDO
THROW ................................................................................................................... 36
1.13. EXCEPCIONES PROPIAS...................................................................................... 36
EJEMPLIFICACIÓN ............................................................................................................... 37

APRENDIZAJE ESPERADO DE LA SEMANA:
• Implementan solución orientada a objetos en plataforma .NET, comprobando
excepciones de sistema.
1. DIFERENCIA LOS COMPONENTES BASE EN EL

DESARROLLO DE UNA CLASE CON PROGRAMACIÓN
ORIENTADA A OBJETOS (POO)
En informática, una clase es una plantilla para la creación de objetos de datos según un
modelo predefinido. Las clases se utilizan para representar entidades o conceptos, como
los sustantivos en el lenguaje. Cada clase es un modelo que define un conjunto de
variables -el estado, y métodos apropiados para operar con dichos datos -el
comportamiento. Cada objeto creado a partir de la clase se denomina instancia de la clase.
Las clases de objetos son un pilar fundamental de la programación orientada a objetos.
Permiten abstraer los datos y sus operaciones asociadas al modo de una caja negra. Los
lenguajes de programación que soportan clases difieren sutilmente en su soporte para
diversas características relacionadas con clases. La mayoría soportan diversas formas de
herencia. Muchos lenguajes también soportan características para proporcionar
encapsulación, como especificadores de acceso.
Una clase también puede tener una representación (metaobjeto) en tiempo de ejecución,
que proporciona apoyo en tiempo de ejecución para la manipulación de los metadatos
relacionados con la clase.
1.1. PROGRAMACIÓN ORIENTADA A OBJETOS
La programación orientada a objetos (POO, en español; OOP, según sus siglas en inglés)
es un paradigma de programación que viene a innovar la forma de obtener resultados. Los
objetos manipulan los datos de entrada para la obtención de datos de salida específicos,
donde cada objeto ofrece una funcionalidad especial.
Muchos de los objetos prediseñados de los lenguajes de programación actuales permiten la
agrupación en bibliotecas o librerías, sin embargo, muchos de estos lenguajes permiten al
usuario la creación de sus propias bibliotecas.
Está basada en varias técnicas: herencia, cohesión, abstracción, polimorfismo,
acoplamiento y encapsulamiento.
Su uso se popularizó a principios de la década de 1990. En la actualidad, existe una gran
variedad de lenguajes de programación que soportan la orientación a objetos.

1.1.1. INTRODUCCIÓN
Los objetos son entidades que tienen un determinado "estado", "comportamiento (método)"
e "identidad":
La identidad es una propiedad de un objeto que lo diferencia del resto; dicho con otras
palabras, es su identificador (concepto análogo al de identificador de una variable o una
constante).
Los métodos (comportamiento) y atributos (estado) están estrechamente relacionados por
la propiedad de conjunto. Esta propiedad destaca que una clase requiere de métodos para
poder tratar los atributos con los que cuenta. El programador debe pensar indistintamente
en ambos conceptos, sin separar ni darle mayor importancia a alguno de ellos. Hacerlo
podría producir el hábito erróneo de crear clases contenedoras de información por un lado y
clases con métodos que manejen a las primeras por el otro. De esta manera se estaría
realizando una "programación estructurada camuflada" en un lenguaje de POO.
La programación orientada a objetos difiere de la programación estructurada tradicional, en
la que los datos y los procedimientos están separados y sin relación, ya que lo único que se
busca es el procesamiento de unos datos de entrada para obtener otros de salida. La
programación estructurada anima al programador a pensar sobre todo en términos de
procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos
procedimientos manejan. En la programación estructurada solo se escriben funciones que
procesan datos. Los programadores que emplean POO, en cambio, primero definen objetos
para luego enviarles mensajes solicitándoles que realicen sus métodos por sí mismos.
1.1.2. ORIGEN
Los conceptos de la POO tienen origen en Simula 67, un lenguaje diseñado para hacer
simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard, del Centro de Cómputo
Noruego en Oslo. En este centro se trabajaba en simulaciones de naves, que fueron
confundidas por la explosión combinatoria de cómo las diversas cualidades de diferentes
naves podían afectar unas a las otras. La idea surgió al agrupar los diversos tipos de naves
en diversas clases de objetos, siendo responsable cada clase de objetos de definir sus
"propios" datos y comportamientos. Fueron refinados más tarde en Smalltalk, desarrollado
en Simula en Xerox PARC (cuya primera versión fue escrita sobre Basic) pero diseñado
para ser un sistema completamente dinámico en el cual los objetos se podrían crear y
modificar "sobre la marcha" (en tiempo de ejecución) en lugar de tener un sistema basado
en programas estáticos.
La POO se fue convirtiendo en el estilo de programación dominante a mediados de los
años 1980, en gran parte debido a la influencia de C++, una extensión del lenguaje de
programación C. Su dominación fue consolidada gracias al auge de las interfaces gráficas
de usuario, para las cuales la POO está particularmente bien adaptada. En este caso, se
habla también de programación dirigida por eventos.
Las características de orientación a objetos fueron agregadas a muchos lenguajes
existentes durante ese tiempo, incluyendo Ada, BASIC, Lisp más Pascal, entre otros. La
adición de estas características a los lenguajes que no fueron diseñados inicialmente para
ellas condujo a menudo a problemas de compatibilidad y en la capacidad de mantenimiento

del código. Los lenguajes orientados a objetos "puros", por su parte, carecían de las
características de las cuales muchos programadores habían venido a depender. Para saltar
este obstáculo, se hicieron muchas tentativas para crear nuevos lenguajes basados en
métodos orientados a objetos, pero permitiendo algunas características imperativas de
maneras "seguras". El lenguaje de programación Eiffel de Bertrand Meyer fue un temprano
y moderadamente acertado lenguaje con esos objetivos, pero ahora ha sido esencialmente
reemplazado por Java, en gran parte debido a la aparición de Internet y a la
implementación de la máquina virtual Java en la mayoría de navegadores web. PHP en su
versión 5 se ha modificado; soporta una orientación completa a objetos, cumpliendo todas
las características propias de la orientación a objetos.
1.2. CONCEPTOS FUNDAMENTALES

La POO es una forma de programar que trata de encontrar una solución a estos problemas.
Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos.
Entre ellos destacan los siguientes:
a).- Clase
Una clase se puede definir de las propiedades y comportamiento de un tipo de objeto
concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a
partir de ella.
b).- Herencia
Por ejemplo, herencia de la clase C a la clase D, es la facilidad mediante la cual la clase D
hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y
operaciones hubiesen sido definidos por la misma D. Por lo tanto, puede usar los mismos
métodos y variables registrados como "públicos" (public) en C. Los componentes
registrados como "privados" (private) también se heredan pero se mantienen escondidos al
programador y sólo pueden ser accedidos a través de otros métodos públicos. Para poder
acceder a un atributo u operación de una clase en cualquiera de sus subclases pero
mantenerla oculta para otras clases es necesario registrar los componentes como
"protegidos" (protected), de esta manera serán visibles en C y en D pero no en otras
clases.
c).- Objeto
Instancia de una clase. Entidad provista de un conjunto de propiedades o atributos (datos) y
de comportamiento o funcionalidad (métodos), los mismos que consecuentemente
reaccionan a eventos. Se corresponden con los objetos reales del mundo que nos rodea, o
con objetos internos del sistema (del programa).
d).- Método
Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena
tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el
objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o
la generación de un "evento" con un nuevo mensaje para otro objeto del sistema.

e).- Evento
Es un suceso en el sistema (tal como una interacción del usuario con la máquina, o un
mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje
adecuado al objeto pertinente. También se puede definir como evento la reacción que
puede desencadenar un objeto; es decir, la acción que genera.
f).- Atributos
Características que tiene la clase.
g).- Mensaje
Una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con
ciertos parámetros asociados al evento que lo generó.
h).- Propiedad o atributo
Contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace
los datos visibles desde fuera del objeto y esto se define como sus características
predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método.
i).- Estado interno
Es una variable que se declara privada, que puede ser únicamente accedida y alterada por
un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el
objeto (o clase de objetos). No es visible al programador que maneja una instancia de la
clase.
j).- Componentes de un objeto
Atributos, identidad, relaciones y métodos.
k).- Identificación de un objeto
Un objeto se representa por medio de una tabla o entidad que esté compuesta por sus
atributos y funciones correspondientes.
En comparación con un lenguaje imperativo, una "variable" no es más que un contenedor
interno del atributo del objeto o de un estado interno, así como la "función" es un
procedimiento interno del método del objeto.
1.3. CARACTERÍSTICAS DE LA POO

Existe un acuerdo acerca de qué características contempla la "orientación a objetos". Las
características siguientes son las más importantes:
a).- Abstracción
Denota las características esenciales de un objeto, donde se capturan sus
comportamientos. Cada objeto en el sistema sirve como modelo de un "agente" abstracto
que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos
en el sistema sin revelar "cómo" se implementan estas características. Los procesos, las

funciones o los métodos pueden también ser abstraídos, y, cuando lo están, una variedad
de técnicas es requeridas para ampliar una abstracción. El proceso de abstracción permite
seleccionar las características relevantes dentro de un conjunto e identificar
comportamientos comunes para definir nuevos tipos de entidades en el mundo real. La
abstracción es clave en el proceso de análisis y diseño orientado a objetos, ya que
mediante ella podemos llegar a armar un conjunto de clases que permitan modelar la
realidad o el problema que se quiere atacar.
b).- Encapsulamiento
Significa reunir todos los elementos que pueden considerarse pertenecientes a una misma
entidad, al mismo nivel de abstracción. Esto permite aumentar la cohesión (diseño
estructurado) de los componentes del sistema. Algunos autores confunden este concepto
con el principio de ocultación, principalmente porque se suelen emplear conjuntamente.
c).- Polimorfismo
Comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo
nombre; al llamarlos por ese nombre se utilizará el comportamiento correspondiente al
objeto que se esté usando. O, dicho de otro modo, las referencias y las colecciones de
objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento
en una referencia producirá el comportamiento correcto para el tipo real del objeto
referenciado. Cuando esto ocurre en "tiempo de ejecución", esta última característica se
llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios
más estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y la
sobrecarga de operadores de C++.
d).- Herencia
Las clases no se encuentran aisladas, sino que se relacionan entre sí, formando una
jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de
todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el
encapsulamiento, permitiendo a los objetos ser definidos y creados como tipos
especializados de objetos preexistentes. Estos pueden compartir (y extender) su
comportamiento sin tener que volver a implementarlo. Esto suele hacerse habitualmente
agrupando los objetos en clases, y estas en árboles o enrejados que reflejan un
comportamiento común. Cuando un objeto hereda de más de una clase, se dice que hay
herencia múltiple; siendo de alta complejidad técnica por lo cual suele recurrirse a la
herencia virtual para evitar la duplicación de datos.
e).- Modularidad
Se denomina "modularidad" a la propiedad que permite subdividir una aplicación en partes
más pequeñas (llamadas módulos), cada una de las cuales debe ser tan independiente
como sea posible de la aplicación en sí y de las restantes partes. Estos módulos se pueden
compilar por separado, pero tienen conexiones con otros módulos. Al igual que la
encapsulación, los lenguajes soportan el modularidad de diversas formas.

f).- Principio de ocultación
Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone
una "interfaz" a otros objetos que especifica cómo pueden interactuar con los objetos de la
clase. El aislamiento protege a las propiedades de un objeto contra su modificación por
quien no tenga derecho a acceder a ellas; solamente los propios métodos internos del
objeto pueden acceder a su estado. Esto asegura que otros objetos no puedan cambiar el
estado interno de un objeto de manera inesperada, eliminando efectos secundarios e
interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a
los datos internos del objeto de una manera controlada y limitando el grado de abstracción.
La aplicación entera se reduce a un agregado o rompecabezas de objetos.
g).- Recolección de basura
La recolección de basura (garbage collection) es la técnica por la cual el entorno de objetos
se encarga de destruir automáticamente, y por tanto desvincular la memoria asociada, los
objetos que hayan quedado sin ninguna referencia a ellos. Esto significa que el
programador no debe preocuparse por la asignación o liberación de memoria, ya que el
entorno la asignará al crear un nuevo objeto y la liberará cuando nadie lo esté usando. En
la mayoría de los lenguajes híbridos que se extendieron para soportar el Paradigma de
Programación Orientada a Objetos como C++ u Object Pascal, esta característica no existe
y la memoria debe desasignarse expresamente.
Fuente: https://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos
EJEMPLIFICACIÓN
Para complementar los temas vistos, les invitamos a revisar los documentos llamados:
- Ejemplos de la estructura
- Ejemplos de tipos de variables
Pueden acceder a él a través del menú Recursos complementarios de la unidad 1, Material
complementario.
1.4. LANZAMIENTO DE EXCEPTION

Los programas deben poder controlar los errores que se producen durante la ejecución de
manera uniforme. Common Language Runtime ofrece una gran ayuda para diseñar
software con tolerancia a errores mediante una plataforma que informa a los programas de
los errores de manera uniforme. Todas las operaciones de .NET Framework informan de un
error iniciando excepciones.
Hasta ahora, el modelo de control de errores de un lenguaje dependía de la forma exclusiva
que tenía el lenguaje de detectar los errores y buscarles controladores o del mecanismo de
control de errores proporcionado por el sistema operativo. El tiempo de ejecución
implementa el control de excepciones con las características siguientes:

• Controla las excepciones independientemente del lenguaje que las genera o el
lenguaje que las controla.
• No requiere una sintaxis del lenguaje concreta para controlar las excepciones, si
no que permite que cada lenguaje defina su propia sintaxis.
• Permite que las excepciones se inicien traspasando los límites de los procesos e,
incluso, los equipos.
Las excepciones ofrecen varias ventajas respecto a otros métodos de notificación de error,
como los códigos devueltos. Ningún error pasa desapercibido. Los valores no válidos no se
siguen propagando por el sistema. No es necesario comprobar los códigos devueltos. Es
muy sencillo agregar código de control de excepciones para aumentar la confiabilidad del
programa.
Con objeto de permitir que los métodos respondan frente a circunstancias inesperadas, .net
proporciona una forma alternativa de finalizar la ejecución del método. Esto se logra
mediante la sentencia Throw (Inicia una excepción dentro de un procedimiento). Puede
utilizar la instrucción Throw para interceptar errores dentro del código, porque Visual Basic
asciende por la pila de llamadas hasta que encuentra el código de control de excepciones
apropiado.
a).- Throw [referencia]
En donde la referencia corresponde a un objeto de alguna subclase de la clase Exception –
una clase que representa situaciones inesperadas. La sentencia throw suele adoptar la
forma siguiente:
b).- Throw New Clase-de-Exception (argumento de tipo String)
En donde Clase-de-Exception es una subclase de Exception.
Un constructor de Exception admite como argumento un String que se imprimirá cuando se
visualice la cadena de invocaciones. Esto permite que quien lance la Exception otorgue un
rótulo a esa Exception con objeto de aportar información adicional.
Por ejemplo: En el siguiente código se utiliza la instrucción Throw para iniciar una
excepción:
' Throw es una nueva excepción.
Throw New System.Exception("Una excepción ha ocurrido.")
Esto sería el resultado:

Figura 1: Resultado
Fuente:://www.elguille.info/colabora/NET2005/percynet_exception01.jpg
Si eres curioso te darás cuenta que en la parte de Información adicional se encuentra

nuestro mensaje que habíamos definido previamente más arriba.
Cuando un método ejecuta la sentencia Throw, se dice que lanza una excepción. Se puede
considerar, por ejemplo, la cadena de invocaciones de métodos que da lugar a la
invocación de un método particular. El primer método que se ejecuta es main. Éste invoca a
un método que a su vez invoca a otro método y así sucesivamente hasta llegar al método
que se encuentra con la situación inesperada.
Si se produce una excepción en un método que no esté preparado para controlarla, la
excepción se propagará de vuelta al método de llamada o al método anterior. Si el método
anterior tampoco tiene controlador de excepciones, la excepción se propagará de vuelta al
llamador del método, y así sucesivamente. La búsqueda de un controlador continuará hasta
la pila de llamadas, que es la serie de procedimientos a los que se llama dentro de la
aplicación. Si ésta tampoco encuentra un controlador para la excepción, se mostrará un
mensaje de error y la aplicación finalizará.
En la siguiente figura puede observarse todo el proceso de desencadenamiento en
búsqueda de un controlador para administrar el error.

Figura 2: Proceso de desencadenamiento
Fuente: http://www.elguille.info/colabora/NET2005/percynet_exception02.jpg
El lanzamiento de una Exception da lugar a que el método que se está ejecutando finalice
inmediatamente. Sin embargo, la sentencia throw no proporciona un valor, ni tampoco
quien haya efectuado la llamada reanuda la ejecución desde el punto en que se ha
producido la invocación. Lo que ocurre es que la Exception lanzada va pasando por todas
las invocaciones habidas a lo largo de la cadena, obligando a que todos los métodos
invocados vayan finalizando. Para todos los métodos que se encuentran en el camino,
parece que el método fuera el que hubiera lanzado la Exception. De hecho, se puede decir
que todos los métodos hallados a lo largo del camino lanzan la Exception. Finalmente, la
cadena llegará al método main que ha hecho comenzar la ejecución, momento en el cual
concluye el programa. Por tanto, la sentencia
c).- Throw [referencia-de-objeto-Exception]
...da lugar a que el programa concluya. Se puede pensar que se trata de una escotilla de
escape. Sin embargo, la instrucción Throw inicia una excepción que se puede controlar con
código de control estructurado de excepciones (Try...Catch...Finally) o con código de
control no estructurado de excepciones (On Error GoTo).

1.4.1. TIPOS DE ERRORES
En Visual Basic, los errores (también denominados excepciones) se dividen en tres
categorías: errores sintácticos, errores en tiempo de ejecución y errores lógicos.
a).- Errores sintácticos
Los errores sintácticos son aquellos que aparecen mientras se escribe el código. Visual
Basic va comprobando el código a medida que se escribe y notifica los errores que detecta,
como la escritura incorrecta de una palabra o el uso incorrecto de un elemento del lenguaje.
Los errores sintácticos son los errores más frecuentes. Se pueden corregir fácilmente en el
entorno de codificación en cuanto se producen.
Nota La instrucción Option Explicit se utiliza para evitar que se produzcan errores
sintácticos, ya que obliga al programador a declarar, por anticipado, todas las variables que
se vayan a utilizar en la aplicación. De este modo, cuando se utilicen las variables en el
código, cualquier error tipográfico que se produzca se capturará de forma inmediata, y
podrá corregirse.
b).- Errores en tiempo de ejecución
Los errores en tiempo de ejecución son aquellos que aparecen solamente después de la
compilación y la ejecución del código. Pueden darse errores de este tipo, por ejemplo, en
fragmentos de código aparentemente correctos, por no presentar errores sintácticos, pero
que no se ejecutan correctamente. Por ejemplo, podría escribir correctamente una línea de
código que abre un archivo. Pero, si el archivo está dañado, la aplicación no podrá ejecutar
la función Open, y se detendrá su ejecución. La mayoría de los errores de este tipo pueden
corregirse modificando el código que presenta errores, para después compilarlo y volver a
ejecutarlo.
c).- Errores lógicos
Los errores lógicos son aquellos que aparecen cuando la aplicación está en
funcionamiento. Normalmente se manifiestan en forma de resultados inesperados o no
deseados en respuesta a las acciones del usuario. Por ejemplo, una clave mal escrita u
otra influencia externa podría hacer que la aplicación dejase de funcionar aun siendo
correctos los parámetros, o que simplemente no funcionase. Por lo general, los errores
lógicos son los más difíciles de corregir, puesto que no siempre está claro dónde se
originan.
1.4.2. MANEJO DE LO INESPERADO

a).- Manejo estructurado de excepciones
Las excepciones son conceptos del sistema con un enfoque estructurado, el cual es
implementado por el Motor de ejecución común de los lenguajes .NET, es posible atrapar
una excepción en un nivel externo de la ejecución. Incluso es posible tener excepciones
anidadas: si un manejador de errores por sí mismo lanza una excepción, también puede ser
atrapada y todavía se puede examinar la razón del error original.
b).- Forma sintáctica de manejo:

Un manejo de excepción se implementa utilizando la instrucción de bloque
Try…Catch…Finally.
El motor de ejecución empieza a ejecutar el bloque Try. Cuando se lanza una excepción, el
motor de ejecución examina la pila de llamadas, una lista de las llamadas de función
creadas por el programa que se está ejecutando actualmente. Esta ruta de ejecución puede
tener varias funciones. Por ejemplo, si Main() invoca FirstMethod() y ese método invoca
SecondMethod() y ese método invoca ThirdMethod(), todos éstos están en la pila de
invocaciones.
La excepción asciende por la pila de invocaciones a cada bloque de excepciones que los
abarca. Debido a que la pila no es modificada, cada bloque de excepción recibe la
oportunidad de manejar la excepción. Si la excepción puede ser resuelta por una de las
instrucciones Catch, ejecuta la instrucción de manejo. Si la excepción no concuerda con
ninguna de las instrucciones Catch en el bloque de excepción, la pila está nuevamente sin
modificación y la excepción se presenta al siguiente método. Si la excepción recorre todo el
camino hacia el inicio del programa (por ejemplo, a Main()) y no ha sido manejada, el motor
de ejecución muestra un cuadro de diálogo que declara que ha ocurrido una excepción no
manejada.
Observe que el desenrollado de pila sólo va en una dirección. Debido a que la pila no está
dañada, se destruyen los objetos. Una vez que se maneja la excepción, el programa
continúa después del bloque Try de la instrucción Catch que manejó la excepción. Si el
bloque Try ha sido ejecutado sin haber lanzado una excepción, o un bloque Catch (un
manejador de excepciones) ha sido ejecutado, se ejecuta el bloque Finally correspondiente
al bloque Try o Catch que acaba de terminar. Este bloque normalmente se limpia después
del algoritmo. (ver figura anterior)
Nota: Todo referente tan sólo a Control no estructurado de excepciones fue tomado de la
ayuda de Microsoft, pero no me limito a esto, al final agrego un ejemplo 02, la cual ilustra
mejor la práctica de control no estructurado de excepciones.
Por omisión la sentencia Throw desencadena una colección de finalizaciones de métodos,
comenzando por el método que ejecuta la sentencia Throw y acabando en el método main
del programa, dando lugar a la conclusión del programa en sí. Esto suele ser una forma
excesivamente brutal de tratar una situación inesperada. Suele ser posible que el programa
responda a lo inesperado y se recupere.
c).- ¿Cómo puede un método responder a una Exception lanzada por otro método
que haya invocado?
.net proporciona una forma en que los métodos pueden capturar cualquier Exception que
les llegue, habiendo sido lanzada por algún método que hayan invocado. La captura de una
Exception significa romper la cascada de lanzamiento de Exception que da lugar a la
terminación del programa. En este caso, el método que captura la Exception recupera el
control y entonces puede – se espera – manejar la situación de una forma menos extrema
que una abrupta terminación del programa.
Para capturar una Exception, las sentencias que contengan invocaciones de métodos que
lancen Exceptions tienen que ir encerradas (para vb .net, por ejemplo) entre las palabras
reservadas Try ... Catch:

Try
AlgunObjetoNet.AlgunMetodoNet()
Catch ex As Exception
....
End Try
A continuación, de la palabra reservada Catch debe ir una declaración de una variable

referencia que hará alusión al objeto Exception lanzado. Esto en el código anterior sería:
... Catch ex As Exception ....
Después de esto viene una colección de sentencias encerradas entre llaves. Si se lanza
una excepción, entonces se ejecutarán esas sentencias cuando el
objeto Exception alcance este método:
Try
AlgunObjetoNet.AlgunMetodoNet()
[sentencias que se ejecutan si y sólo si el código
contenido en el bloque Try lanza una excepción]
End Try
El código que aparece entre las llaves que siguen a la palabra reservada Try es lo que se
denomina el bloque Try; también diremos que este código está rodeado por un Try...Catch.
El código que aparece después del match es lo que examina el bloque catch.
Pueden declararse varias referencias a objetos Exceptions:
Dim MyDate As Object 'Debe contener un date/time
Dim MyNextDate As Date 'para almacenar el año; truncado al valor integral.
Try
MyNextDate = DateAdd("yyyy", 100, MyDate)
Catch ThisExcep As System.ArgumentException
' El argumento proporcionado para el método no es válido.
Catch ThisExcep As ArgumentOutOfRangeException

'el valor del argumento se encuentra fuera del intervalo de valores
'permitido definido por el método invocado.Esta excepción se dará
'cuando el resultado está después del 31 Diciembre de 9999.
Catch ThisExcep As InvalidCastException
'La fecha obtenida no puede ser convertida a date/time.
End Try
El paso final en la captura de una excepción es proporcionar un mecanismo que limpie el

estado del método antes (posiblemente) de permitir que el control pase a otra parte
diferente del programa. Se puede hacer esto encerrando el código de limpieza dentro de
un bloque Finally
Dim MyDate As Object 'Debe contener un date/time

Dim MyNextDate As Date 'para almacenar el año; truncado al valor integral.
Try
MyNextDate = DateAdd("yyyy", 100, MyDate)
Catch ThisExcep As System.ArgumentException
' El argumento proporcionado para el método no es válido.

Catch ThisExcep As ArgumentOutOfRangeException
'el valor del argumento se encuentra fuera del intervalo de valores
'permitido definido por el método invocado.Esta excepción se dará
'cuando el resultado está después del 31 Diciembre de 9999.
Catch ThisExcep As InvalidCastException
'La fecha obtenida no puede ser convertida a date/time.
Finally
'sentencias que se ejecutan independientemente si ocurrió o no el lanzamiento de la
excepción.
End Try
El sistema de ejecución siempre ejecuta las sentencias que hay dentro del bloque Finally
sin importar lo que suceda dentro del bloque Try.

d).- Lanzar excepciones propias
También se pueden lanzar excepciones propias, extendiendo la clase System.Exception.
Por ejemplo:
'Construimos nuestra propia clase Exception para lanzar excepciones.

Public Class MiExcepcion
Inherits System.Exception
Sub New()
End Sub
'aplicando conceptos de polimorfismo...
Public Overrides Function ToString() As String
Return "Error:'Division entre cero no es posible'"
End Function
End Class
Public Function divide(ByVal x As Integer, ByVal y As Integer) As Integer

Dim z As Integer
Try
z=x/y
Catch ex As System.ArithmeticException
z = -1
Throw New MiExcepcion 'lanzamos la excepción.

Return z
End Try
End Function
Private Sub BtnCalcular_Click(ByVal sender As System.Object, ByVal e As System.Ev

entArgs) Handles BtnCalcular.Click
Dim x, y As Double
Dim r As Double = 0
Try
x = Double.Parse(Me.TextDividendo.Text)
y = Double.Parse(Me.TextDivisor.Text)
MsgBox("Ingrese números")
Me.TextDividendo.Clear()
Me.TextDivisor.Clear()
Me.TextResultado.Text = "Operación sin éxito"
Return
End Try

Try
r = divide(x, y)
C atch ex As MiExcepcion 'capturamos la excepción que habíamos lanzado.
Me.TextResultado.Text = ex.ToString()
r = -1
End Try
If (r <> -1) Then

Dim z As Double = CType(x / y, Double)
Me.TextResultado.Text = z
End If
End Sub
Estos son los resultados. Si ingreso un número y una cadena String, desde luego que debe
desencadenarse una excepción.
Figura 3: Manejo de excepciones

También debe originarse una excepción, al intentar dividir entre cero. Recuerda que esta
excepción la estamos manejando mediante la clase que habíamos extendido de la clase
System.Exception.

Figura 4: Manejo de excepciones error
Por muchas razones podemos obviar u olvidarnos de manejar o controlar ciertas

excepciones fatales durante el desarrollo de un proyecto, aplicación o yo que sé lo que
estés desarrollando.
Hago este comentario debido a que existe maneras de controlar de manera genérica todos
estas excepciones "inesperadas". Inserta este código en la parte inicial de tu aplicación...y
te habrás evitado grandes sustos.
Public Class Form1
Inherits System.Windows.Forms.Form
'[aquí va el Código generado por el diseñador de Windows
Form]
Public Shared Sub main() 'implementando un Controlador genérico
de excepciones...
Try Application.Run(New
Form1) 'Form1 viene a ser el nombre de nuestro
formulario.
MsgBox(ex.InnerException.ToString)
End Try
End Sub

'.....[demás eventos, procedimientos y
funciones...]
End Class
1.5. CONTROL NO ESTRUCTURADO DE EXCEPCIONES

En el caso del control no estructurado de excepciones, se coloca una instrucción On Error
al principio de un bloque de código, En el caso del control no estructurado de excepciones,
se coloca una instrucción On Error al principio de un bloque de código, que controla todos
los errores que se producen dentro del bloque. Cuando se genera una excepción en un
procedimiento después de que se haya ejecutado la instrucción On Error, el programa salta
al argumento line especificado en la instrucción On Error. El argumento line, que es
cualquier etiqueta de línea o número de línea, indica la ubicación del controlador de
excepción.
A veces se efectúa una llamada desde el procedimiento original hasta otro procedimiento, y
se produce una excepción en el procedimiento al que se llama. En estos casos, si el
procedimiento al que se llama no controla la excepción, ésta se propaga de vuelta al
procedimiento que realiza la llamada y la ejecución salta al argumento line.
Nota: El método de control de errores no estructurado por medio de On Error puede
degradar el rendimiento de la aplicación y puede dificultar la depuración y el mantenimiento
del código. Se recomienda utilizar el método de control de errores estructurado.
1.5.1. ON ERROR GOTO LINE

La instrucción On Error GoTo Line presupone que el código de control de errores comienza
en la línea especificada en el argumento line requerido. Si se produce un error en tiempo de
ejecución, el control se transfiere a la etiqueta o al número de línea especificado en el
argumento, con lo que se activa el controlador de errores. La línea especificada debe estar
en el mismo procedimiento que la instrucción On Error GoTo Line; de lo contrario, Visual
Basic generará un error de compilación. En el siguiente ejemplo se muestra el uso de un
controlador de errores con una etiqueta de línea:
Sub TestSub
On Error GoTo ErrorHandler
' Code that may or may not contain errors.
Exit Sub
ErrorHandler:
' Code that handles errors.
Resume

End Sub
El ejemplo contiene un controlador de errores denominado ErrorHandler. Si el código de la

subrutina TestSub genera un error, Visual Basic ejecuta de forma inmediata el código que
sigue a la etiqueta ErrorHandler. Al final del bloque de control de errores, la instrucción
Resume transfiere el control de nuevo a la línea de código en la que se produjo el error por
primera vez. Después continúa la ejecución del resto de la subrutina como si no se hubiese
producido ningún error.
Nota: Debe colocar una instrucción Exit Sub inmediatamente antes de bloque de control de
errores. De lo contrario, Visual Basic ejecutará el código de control de errores cuando
llegue al final de la subrutina, lo que puede provocar resultados inesperados o no
deseados.
1.5.2. ON ERROR RESUME NEXT

La instrucción On Error Resume Next especifica que, en caso de que se produzca un error
en tiempo de ejecución, el control pase a la instrucción inmediatamente siguiente a aquélla
en que se haya producido el error. La ejecución continúa en ese punto. On Error Resume
Next permite colocar las rutinas de control de errores en los lugares donde se prevea que
pueden producirse, en lugar de transferir el control a otro punto del procedimiento.
Nota : Si un procedimiento llama a otro procedimiento, la instrucción On Error Resume
Next permanece inactiva durante la ejecución del procedimiento al que se ha llamado. Por
lo tanto, debe colocar una instrucción On Error Resume Next en cada procedimiento al que
se llame que la necesite. Esto es necesario porque el comportamiento de Resume Next
sólo se aplica al procedimiento que contiene la instrucción On Error Resume Next. Si se
produce un error no controlado en un procedimiento al que se ha llamado, la excepción se
propaga de vuelta al procedimiento que realizó la llamada, y la ejecución se reanuda en la
instrucción siguiente a la del procedimiento de llamada. Es estos casos, no se controla el
error.
Resume también puede utilizarse de forma independiente, fuera de la instrucción On Error.
Si se utiliza Resume de esta forma, Visual Basic devuelve el control a la instrucción que
provocó el error. Resume suele utilizarse después de que un controlador de errores corrija
el error.
Visual Basic dispone también de la instrucción Resume Next, que dirige el control a la línea
inmediatamente posterior a la línea de código que ha provocado el error. Debería utilizar
Resume Next en aquellos casos en los que un error no detenga la ejecución de la
aplicación. También debería utilizarla si un error dado no cambia el resultado esperado de
la subrutina.
Otra variación de la instrucción Resume es Resume Line, que es similar a On Error GoTo
Line. Resume Line pasa el control a la línea que se especifique en el argumento line.
Resume Line sólo puede utilizarse dentro de un controlador de errores.
Nota: A la hora de depurar el código, debe deshabilitar la instrucción On Error Resume
Next.

1.5.3. ON ERROR GOTO 0
La instrucción On Error GoTo 0 deshabilita cualquier control de errores del procedimiento
actual. Si no incluye una instrucción On Error GoTo 0, el controlador de errores se
deshabilita igualmente cuando finaliza el procedimiento que contiene el controlador de
excepción.
Nota La instrucción On Error GoTo 0 no pretende especificar la línea 0 como el inicio del
código de control de errores, aunque el procedimiento contenga una línea con el número 0.
1.5.4. ON ERROR GOTO -1

La instrucción On Error GoTo -1 deshabilita todos los controladores de excepciones del
procedimiento actual. Si no incluye una instrucción On Error GoTo -1, la excepción se
deshabilita automáticamente cuando finaliza el procedimiento.
Nota La instrucción On Error GoTo -1 no pretende especificar la línea -1 como el inicio del
código de control de errores, aunque el procedimiento contenga una línea con el número -1.
Ejemplo 01
En el código que se muestra a continuación, el controlador de excepciones se denomina
MyException y ya no controla un error específico, sino varios errores, como por ejemplo, el
de intentar ingresar datos de tipo cadena y luego de ingresar un número, controla de que
este sea tipo Byte, es decir el ingreso correcto debe ser un número de tipo Byte [entre 0 y
255]. Si el error es otro, Visual Basic genera un error en tiempo de ejecución y muestra el
número que identifica al error.
Public Class Form1
Inherits System.Windows.Forms.Form
'[aquí va el Código generado por el diseñador de Windows Form]
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As

System.EventArgs) Handles Button1.Click
Dim n As Byte
On Error GoTo MyException

n = CType(Me.TextBox1.Text, Byte)
MsgBox("Usted escribió " & n.ToString, MsgBoxStyle.Information, "Ingreso de datos
correctos" )
Exit Sub
MyException:
Select Case Err.Number
Case 6 : MsgBox("Escriba un número entre 0 y 255", MsgBoxStyle.Exclamation,

"On Error GoTo")

Case 13 : MsgBox("Sólo se admiten números", MsgBoxStyle.Exclamation, "On Error
GoTo")
Case Else
MsgBox(Err.Description & ": " & Err.Number.ToString, MsgBoxStyle.Exclamation,
"On Error GoTo")
End Select
Me.TextBox2.Text = "Err.LastDllError: " +
Err.LastDllError.ToString + _
vbCrLf + "err.Source: " + Err.Source + _
vbCrLf + "err.Number: " + Err.Number.ToString + _
vbCrLf + "err.HelpFile: " + Err.HelpFile.ToString + _
vbCrLf + "err.HelpContext: " + Err.HelpContext.ToString + _
vbCrLf + "Err.Description: " +

Err.Description.ToString
End Sub
1.6. JERARQUÍA DE EXCEPCIONES DEL MOTOR DE TIEMPO DE

EJECUCIÓN
El motor de tiempo de ejecución tiene un conjunto base de excepciones que derivan de
SystemException, que inicia cuando está ejecutando instrucciones individuales. En la tabla
siguiente se muestran jerárquicamente las excepciones estándar que proporciona el motor
de tiempo de ejecución y las condiciones en que se debe crear una clase derivada. Los
nombres de las excepciones indican la condición de error que representan. Las siguientes
son las excepciones predefinidas más frecuentes que se pueden encontrar:
Tipo de excepción Tipo base Descripción Ejemplo
Exception Object Clase base Ninguno (utilice una clase

de todas las derivada de esta excepción).
excepciones.
SystemException Exception Clase base Ninguno (utilice una clase

de todos los derivada de esta excepción).
errores que
genera el
motor de
tiempo de

ejecución.
IndexOutOfRangeException SystemException La inicia el Indización de una matriz fuera

motor de de su intervalo válido:
tiempo de
ejecución arr[arr.Length+1]
sólo cuando
no se indiza
correctament
e una matriz.
NullReferenceException SystemException La inicia el object o = null;

motor de
tiempo de o.ToString();
ejecución
sólo cuando
se hace
referencia a
un objeto
nulo.
InvalidOperationException SystemException La inician los Llamar

métodos que a Enumerator.GetNext() despu
se és de eliminar un Item de la
encuentran colección subyacente.
en un estado
no válido.
ArgumentException SystemException Clase base Ninguno (utilice una clase

de todas las derivada de esta excepción).
excepciones
de
argumento.
ArgumentNullException ArgumentExceptio La inician los String s = null;

n métodos que
no permiten "Calculate".IndexOf (s);
que un
argumento
sea nulo.
ArgumentOutOfRangeExceptio ArgumentExceptio La inician los String s = "string";

n n métodos que
comprueban s.Chars[9];
que los
argumentos
están en un
intervalo
dado.
ExternalException SystemException Clase base Ninguno (utilice una clase

de las derivada de esta excepción).
excepciones

que se
producen a o
van dirigidas
a entornos
fuera del
motor de
tiempo de
ejecución.
ComException ExternalException Excepción Se usa en la interoperabilidad

que COM.
encapsula
información
de HRESULT
de COM.
SEHException ExternalException Excepción Se usa en la interoperabilidad

que de código no administrado.
encapsula
información
de control de
excepciones
estructurada
de Win32.
1.7. CONCEPTO DE EXCEPCIÓN

Las excepciones son el mecanismo recomendado en la plataforma .NET para la
propagación de errores que se produzcan durante la ejecución de las aplicaciones
(divisiones por cero, intentos de lectura de archivos dañados, etc.) Básicamente una
excepción es un objeto derivado de System.Exception que se genera cuando en tiempo de
ejecución se produce algún error y que contiene información sobre el mismo.
a).- Claridad: utilizando excepciones es posible escribir el código como si nunca se
fuesen a producir errores y dejar en una zona aparte todo el código de tratamiento
de errores, lo que contribuye a facilitar la legibilidad de los fuentes.
b).- Más información: una excepción es un objeto que cuenta con campos que
describen las causas del error y a cuyo tipo suele dársele un nombre que resuma
claramente su causa. Por ejemplo, para informar errores de división por cero se
suele utilizar una excepción predefinida de tipo DivideByZeroException en cuyo
campo Message se detallan las causas del error producido
c).- Tratamiento asegurado: Cuando se usan excepciones siempre se asegura que
el programador trate toda excepción que pueda producirse o que, si no lo hace, se
aborte la ejecución de la aplicación mostrándose un mensaje indicando dónde se ha
producido el error.

1.7.1. LA CLASE SYSTEM.EXCEPTION
Como ya se ha dicho, todas las excepciones derivan de un tipo predefinido en la BCL
llamado System.Exception. Los principales miembros que heredan de este son:
a).- String Message {virtual get;}: Contiene un mensaje descriptivo de las causas de la
excepción. Por defecto este mensaje es una cadena vacía (“”)
b).- Exception InnerException {virtual get;}: Si una excepción fue causada como
consecuencia de otra, esta propiedad contiene el objeto System.Exception que representa
a la excepción que la causó. Así se pueden formar cadenas deexcepciones de cualquier
longitud. Si se desea obtener la última excepción de la cadena es mejor usar el método
virtual Exception GetBaseException()
c).- String StackTrace {virtual get;}: Contiene la pila de llamadas a métodos que se tenía
en el momento en que se produjo la excepción. Esta pila es una cadena con información
sobre cuál es el método en que se produjo la excepción, cuál es el método que llamó a
este, cuál es el que llamó a ese otro, etc.
d).- String Source {virtual get; virtual set;}: Almacena información sobre cuál fue la
aplicación u objeto que causó la excepción.
e).- MethodBase TargetSite {virtual get;}: Almacena cuál fue el método donde se produjo
la excepción en forma de objeto System.Reflection.MethodBase. Puede consultar la
documentación del SDK si desea cómo obtener información sobre las características del
método a través del objeto MethodBase.
f).- String HelpLink {virtual get;}: Contiene una cadena con información sobre cuál es la
URI donde se puede encontrar información sobre la excepción. El valor de esta cadena
puede establecerse con virtual Exception SetHelpLink (string URI), que devuelve la
excepción sobre la que se aplica pero con la URI ya actualizada.
Para crear objetos de clase System.Exception se puede usar los constructores:
Exception()
Exception(string msg)
Exception(string msg, Exception causante)
1.7.2. EXCEPCIONES PREDEFINIDAS COMUNES

En el espacio de nombres System de la BCL hay predefinidas múltiples excepciones
derivadas de System.Exception que se corresponden con los errores más comunes que
pueden surgir durante la ejecución de una aplicación. En la Tabla se recogen algunas:
Tipo de la excepción Causa de que se produzca la excepción

ArgumentException Pasado argumento no válido (base de excepciones de
argumentos)
ArgumentNullException Pasado argumento nulo
ArgumentOutOfRangeException Pasado argumento fuera de rango

ArrayTypeMistmatchException Asignación a tabla de elemento que no es de su tipo
COMException Excepción de objeto COM
DivideByZeroException División por cero
IndexOutOfRangeException Índice de acceso a elemento de tabla fuera del rango válido
(menor que cero o mayor que el tamaño de la tabla)
InvalidCastException Conversión explícita entre tipos no válida

InvalidOperationException Operación inválida en estado actual del objeto
InteropException Base de excepciones producidas en comunicación con
código inseguro
NullReferenceException Acceso a miembro de objeto que vale null
OverflowException Desbordamiento dentro de contexto donde se ha de
comprobar los desbordamientos (expresión constante,
instrucción checked, operanción checked u opción del
compilador /checked)
OutOfMemoryException Falta de memoria para crear un objeto con new
SEHException Excepción SHE del API Win32
StackOverflowException Desbordamiento de la pila, generalmente debido a un
excesivo número de llamadas recurrentes.
TypeInizializationException Ha ocurrido alguna excepción al inicializar los campos
estáticos o el constructor estático de un tipo. En
InnerException se indica cuál es.
Tabla proporcionada por: https://programacion.net/articulo/el_lenguaje_de_programacion_c_167/17
1.7.3. LANZAMIENTO DE EXCEPCIONES. INSTRUCCIÓN THROW

Para informar de un error no basta con crear un objeto del tipo de excepción apropiado,
sino que también hay pasárselo al mecanismo de propagación de excepciones del CLR. A
esto se le llama lanzar la excepción, y para hacerlo se usa la siguiente instrucción:
throw <objetoExcepciónALanzar>;
Por ejemplo, para lanzar una excepción de tipo DivideByZeroException se podría hacer:
throw new DivideByZeroException();
Si el objeto a lanzar vale null, entonces se producirá una NullReferenceException que será
lanzada en vez de la excepción indicada en la instrucción throw.
1.7.4. CAPTURA DE EXCEPCIONES. INSTRUCCIÓN TRY

Una vez lanzada una excepción es posible escribir código que se encarga de tratarla. Por
defecto, si este código no se escribe la excepción provoca que la aplicación aborte
mostrando un mensaje de error en el que se describe la excepción producida (información
de su propiedad Message) y dónde se ha producido (información de su propiedad
StackTrace) Así, dado el siguiente código fuente de ejemplo:
using System;
class PruebaExcepciones

using System;
class PruebaExcepciones
{
static void Main()
{
A obj1 = new A(); obj1.F();
}
}
class A
{
Public void F()
{
G();
}
static public void G()
{
int c = 0; int d = 2/c;
}
Al compilarlo no se detectará ningún error ya que al compilador no le merece la pena
calcular el valor de c en tanto que es una variable, por lo que no detectará que dividir 2/c no
es válido. Sin embargo, al ejecutarlo se intentará dividir por cero en esa instrucción y ello
provocará que aborte la aplicación mostrando el siguiente mensaje:
Unhandled Exception: System.DivideByZeroException: Attempted to divide by zero.
at PruebaExcepciones.Main()
Como se ve, en este mensaje se indica que no se ha tratado una excepción de división por
cero (tipo DivideByZeroException) dentro del código del método Main() del tipo
PruebaExcepciones. Si al compilar el fuente hubiésemos utilizado la opción /debug, el
compilador habría creado un fichero .pdb con información extra sobre las instrucciones del
ejecutable generado que permitiría que al ejecutarlo se mostrase un mensaje mucho más
detallado:
Unhandled Exception: System.DivideByZeroException: Attempted to divide by zero.
at A.G() in E:\c#\Ej\ej.cs:line 22 at A.F() in E:\c#\Ej\ej.cs:line 16
at PruebaExcepciones.Main() in E:\c#\Ej\ej.cs:line 8

a).- Instrucción try
try
<instrucciones>
catch (<excepción1>)
<tratamiento1>
catch (<excepción2>)
<tratamiento2>
...
finally
<instruccionesFinally>
El significado de try es el siguiente: si durante la ejecución de las <instrucciones> se lanza
una excepción de tipo <excepción1> (o alguna subclase suya) se ejecutan las instrucciones
<tratamiento1>, si fuese de tipo <excepción2> se ejecutaría <tratamiento2>, y así hasta
que se encuentre una cláusula catch que pueda tratar la excepción producida. Si no se
encontrase ninguna y la instrucción try estuviese anidada dentro de otra, se miraría en los
catch de su try padre y se repetiría el proceso. Si al final se recorren todos los trys padres y
no se encuentra ningún catch compatible, entonces se buscaría en el código desde el que
se llamó al método que produjo la excepción. Si así se termina llegando al método que
inició el hilo donde se produjo la excepción y tampoco allí se encuentra un tratamiento
apropiado se aborta dicho hilo; y si ese hilo es el principal (el que contiene el punto de
entrada) se aborta el programa y se muestra el mensaje de error con información sobre la
excepción lanzada ya visto.
Así, para tratar la excepción del ejemplo anterior de modo que una división por cero
provoque que a d se le asigne el valor 0, se podría reescribir G() de esta otra forma:
static public void G()
{
try
{
}
int c = 0; int d = 2/c;
catch (DivideByZeroException)
{ d=0; }
}
También hay que señalar que cuando en <instrucciones> se lance una excepción que sea
tratada por un catch de algún try -ya sea de la que contiene las <instrucciones>, de algún

try padre suyo o de alguno de los métodos que provocaron la llamada al que produjo la
excepción- se seguirá ejecutando a partir de las instrucciones siguientes a ese try.
Fuente: https://docs.microsoft.com/es-es/dotnet/visual-basic/language-reference/statements/try-catch-finally-
statement
1.8. BLOQUES
Cuando se produce una excepción en try un bloque, el sistema busca en catch los bloques
asociados en el orden en el que aparecen en el código de la catch aplicación hasta que
encuentra un bloque que controla la excepción. Un catch bloque controla una excepción de
tipo T si el filtro de tipo del bloque catch especifica T o cualquier tipo que T se derive de. El
sistema detiene la búsqueda después de encontrar el catch primer bloque que controla la
excepción. Por esta razón, en el código de la catch aplicación, un bloque que controla un
tipo debe especificarse antes que un bloque que controla sus tipos base, como se muestra
en el ejemplo que sigue a catch esta sección. Un bloque catch que controla
System.Exception se especifica en último lugar.
Si ninguno de los catch bloques asociados al bloque actual try controla la excepción y el
bloque actual try está anidado dentro de otros try bloques de la llamada actual, los catch
bloques asociados al siguiente se busca try en el bloque de inclusión. Si no catch se
encuentra ningún bloque para la excepción, el sistema busca en los niveles de anidamiento
anteriores de la llamada actual. Si no catch se encuentra ningún bloque para la excepción
en la llamada actual, la excepción se pasa a la pila de llamadas y se busca en el marco de
pila anterior catch un bloque que controla la excepción. La búsqueda de la pila de llamadas
continúa hasta que se controla la excepción o hasta que no existen más fotogramas en la
pila de llamadas. Si se alcanza la parte superior de la pila de llamadas sin catch encontrar
un bloque que controla la excepción, el controlador de excepciones predeterminado lo
controla y la aplicación finaliza.
El bloque finally es opcional, y si se incluye ha de hacerlo tras todas los bloques catch.
Las <instruccionesFinally> de este bloque se ejecutarán tanto si se producen excepciones
en <instrucciones> como si no. En el segundo caso sus instrucciones se ejecutarán tras las
<instrucciones>, mientras que en el primero lo harán después de tratar la excepción pero
antes de seguirse ejecutando por la instrucción siguiente al try que la trató. Si en un try no
se encuentra un catch compatible, antes de pasar a buscar en su try padre o en su método
llamante padre se ejecutarán las <instruccionesFinally>.
using System;
class MiException:Exception {} class Excepciones
{
public static void Main()
{
try
{

Console.WriteLine(“En el try de Main()”); }
Método();
Console.WriteLine(“Al final del try de Main()”);
}
catch (MiException)
{
Console.WriteLine(“En el catch de Main()”);
}
finally
{
Console.WriteLine(“finally de Main()”);
}
}
public static void Método()
{
try
{
Console.WriteLine(“En el try de Método()”);
Método2();
Console.WriteLine(“Al final del try de Método()”);
}
catch (OverflowException)
{
Console.WriteLine(“En el catch de Método()”);
}
finally
{
Console.WriteLine(“finally de Método()”);
}
}

public static void Método2()
{
try
{
Console.WriteLine(“En el try de Método2()”);
throw new MiException();
Console.WriteLine(“Al final del try de Método2()”);
}
catch (DivideByZeroException)
{ Console.WriteLine(“En el catch de Método2()”); } finally
{ Console.WriteLine(“finally de Método2()”); }
}
}
La idea de todo este mecanismo de excepciones es evitar mezclar el código normal con
el código de tratamiento de errores. Así, en <instrucciones> se escribiría el código como
si no se pudiesen producir errores, en las cláusulas catch se tratarían los posibles
errores, y en la cláusula finally se incluiría código a ejecutar tanto si produjesen errores
como si no (suele usarse para liberar recursos ocupados, como fichero o conexiones de
red abiertas), también es posible escribir cada cláusula catch definiendo una variable que
se podrá usar dentro del código de tratamiento de la misma para hacer referencia a la
excepción capturada. Esto se hace con la sintaxis:
catch (<tipoExcepción> <nombreVariable>)
{
<tratamiento>
}
Todas las excepciones derivan de System.Exception, para definir una cláusula catch que
pueda capturar cualquier tipo de excepción basta usar:
catch(System.Exception <nombreObjecto>)
{
<tratamiento>
}

Fuente: https://www.coursehero.com/file/p60obuis/El-bloque-finally-es-opcional-y-si-se-incluye-ha-
de-hacerlo-tras-todas-los/
EJEMPLIFICACIÓN
Para complementar los temas vistos, les invitamos a revisar el documento llamado:
- Ejemplificación de excepción
Pueden acceder a través del menú Recursos complementarios de la unidad 1, Material
complementario.
1.9. EXCEPCIONES - MÚLTIPLES CATCH PARA UN TRY

Podemos definir varios bloques catch para un solo bloque try. Es común que en un bloque
try haya más de un método que pueda elevar excepciones o inclusive un mismo método
puede generar más de un tipo de excepción.
Luego podemos disponer una sintaxis de try/catch:
try {
[instrucciones 1]
} catch([excepción 1]) {
[instrucciones 2]
}
catch([excepción 2]) {
[instrucciones 3]
}
catch([excepción n]) {
[instrucciones n]
}
1.10. EXCEPCIONES - CLASE PADRE EXCEPTION

l API de .Net define numerosas excepciones, algunas de las que vimos en conceptos
anteriores son: FormatException, IndexOutOfRangeException, DivideByZeroException etc.
Todas estas clases tienen en común que heredan directamente o indirectamente de la
clase Exception.
Veamos con un ejemplo las propiedades fundamentales de la clase Exception.
Problema:

Realizar la carga de un número entero por teclado e imprimir su cuadrado.
Programa:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace PruebaExcepcion5
{
class Program
{
static void Main(string[] args)
{
try
{
Console.Write("Ingrese un valor:");
string linea = Console.ReadLine();
var num = int.Parse(linea);
var cuadrado = num * num;
Console.WriteLine($"El cuadrado de {num} es {cuadrado}");
}
catch (FormatException e)
{
Console.WriteLine($"Propiedad Message: {e.Message}\n");
Console.WriteLine($"Propiedad StackTrade: {e.StackTrace}\n");
Console.WriteLine($"Propiedad Source: {e.Source}\n");
Console.WriteLine($"Propiedad TargetSize: {e.TargetSite}");
}
Console.ReadKey();

}
}
}
Si ejecutamos el programa e ingresamos una cadena no numérica podemos ver la
información que nos suministra cada una de estas propiedades:
1.11. EXCEPCIONES - BLOQUE FINALLY

El manejo de excepciones en C# puede incluir otro bloque llamado 'finally':
try {
[instrucciones 1]
} catch([excepción 1]) {
[instrucciones 2]
} finally {
[instrucciones 3]
}
El objetivo de este bloque es liberar recursos que se solicitan en el bloque try. El bloque
finally se ejecuta siempre, inclusive si se genera la captura de una excepción.
Los recursos más comunes que se deben liberar son las conexiones a bases de datos, uso
de archivos y conexiones de red. Un recurso que no se libera impide que otro programa lo
pueda utilizar. Al disponer la liberación de recursos en el bloque 'finally' nos aseguramos
que todo recurso se liberará, inclusive aunque se dispare una excepción.
Tener en cuenta que si no se disparan ninguna excepción en un bloque try luego de esto se
ejecuta el bloque 'finally'.
El bloque finally es opcional y en el caso de estar presente se coloca después del último
bloque catch.

1.12. EXCEPCIONES - LANZAR UNA EXCEPCIÓN MEDIANTE
COMANDO THROW
Hemos visto hasta ahora cual es la sintaxis para capturar excepciones que lanzan métodos.
Ahora veremos cómo podemos lanzar una excepción para que sea eventualmente
capturada posteriormente.
Hay que definir con juicio que métodos de una clase deben lanzar excepciones cuando el
dato es incorrecto debido que luego se hace más difícil consumir dicho método.
Aquellas partes críticas de nuestras clases pueden lanzar excepciones para que sean más
robustas. Por ejemplo si tenemos una clase 'ClienteBanco' y queremos controlar que nunca
pueda sacar más dinero del que tiene depositado, el método extraer puede lanzar una
excepción evitando que quede en negativo el monto del cliente.
1.13. EXCEPCIONES PROPIAS

La librería .Net proporciona gran cantidad de clases que manejan casi cualquier tipo de
excepción, pero no estamos obligados a utilizar solo esas clases sino que podemos crear
nuestras propias excepciones.
Si queremos crear una excepción deberemos heredar de Exception o de alguna de sus
subclases.
Veamos con un ejemplo como crear una clase que herede de Exception, luego en otra
clase lanzar una excepción de la nueva clase creada y finalmente llamar al método que
lanza la excepción.
Ejemplo Problema:
Confeccionar una clase que administre una lista tipo pila (se debe poder insertar, extraer e
imprimir los datos de la pila).
En el método extraer lanzar una excepción si la pila se encuentra vacía, crear una
excepción propia que herede de Exception.
Clase: PilaVaciaException
public class PilaVaciaException extends Exception {
public PilaVaciaException(String mensaje) {

super("Problema:" + mensaje);
}
}
La clase 'PilaVaciaException' hereda de la clase 'Exception', esto significa que quien lance
una excepción de este tipo luego deberá ser capturada en forma obligatoria.

Fuente:
https://www.tutorialesprogramacionya.com/javaya/detalleconcepto.php?punto=86&codigo=166&inicio
=80
EJEMPLIFICACIÓN
Para complementar los temas vistos, les invitamos a revisar el documento llamado:
- Ejemplificación excepciones – múltiples catch para un try
Pueden acceder a través del menú Recursos complementarios de la unidad 1, Material
complementario.

V1 Contenidos Unidad 1 Semana 5

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

V1 Contenidos Unidad 1 Semana 5

Cargado por

Copyright:

Formatos disponibles

TALLER DE PROGRAMACIÓN.

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 2

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 3

1. DIFERENCIA LOS COMPONENTES BASE EN EL

1.1. PROGRAMACIÓN ORIENTADA A OBJETOS

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 4

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 5

1.2. CONCEPTOS FUNDAMENTALES

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 6

1.3. CARACTERÍSTICAS DE LA POO

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 7

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 8

1.4. LANZAMIENTO DE EXCEPTION

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 9

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 10

Si eres curioso te darás cuenta que en la parte de Información adicional se encuentra

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 11

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 12

1.4.2. MANEJO DE LO INESPERADO

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 13

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 14

A continuación, de la palabra reservada Catch debe ir una declaración de una variable

[sentencias que se ejecutan si y sólo si el código

contenido en el bloque Try lanza una excepción]

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 15

El paso final en la captura de una excepción es proporcionar un mecanismo que limpie el

Dim MyDate As Object 'Debe contener un date/time

' El argumento proporcionado para el método no es válido.

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 16

'Construimos nuestra propia clase Exception para lanzar excepciones.

Public Function divide(ByVal x As Integer, ByVal y As Integer) As Integer

Throw New MiExcepcion 'lanzamos la excepción.

Private Sub BtnCalcular_Click(ByVal sender As System.Object, ByVal e As System.Ev

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 17

C atch ex As MiExcepcion 'capturamos la excepción que habíamos lanzado.

If (r <> -1) Then

Figura 3: Manejo de excepciones

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 18

Por muchas razones podemos obviar u olvidarnos de manejar o controlar ciertas

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 19

1.5. CONTROL NO ESTRUCTURADO DE EXCEPCIONES

1.5.1. ON ERROR GOTO LINE

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 20

El ejemplo contiene un controlador de errores denominado ErrorHandler. Si el código de la

1.5.2. ON ERROR RESUME NEXT

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 21

1.5.4. ON ERROR GOTO -1

'[aquí va el Código generado por el diseñador de Windows Form]

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As

On Error GoTo MyException

Select Case Err.Number

Case 6 : MsgBox("Escriba un número entre 0 y 255", MsgBoxStyle.Exclamation,

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 22

vbCrLf + "err.Source: " + Err.Source + _

vbCrLf + "err.Number: " + Err.Number.ToString + _

vbCrLf + "err.HelpFile: " + Err.HelpFile.ToString + _

vbCrLf + "err.HelpContext: " + Err.HelpContext.ToString + _

vbCrLf + "Err.Description: " +

1.6. JERARQUÍA DE EXCEPCIONES DEL MOTOR DE TIEMPO DE

Tipo de excepción Tipo base Descripción Ejemplo

Exception Object Clase base Ninguno (utilice una clase

SystemException Exception Clase base Ninguno (utilice una clase

Taller de Bases de datos / Diseño e implementación de Bases de Datos en SQL 23

IndexOutOfRangeException SystemException La inicia el Indización de una matriz fuera