Texto con diagramas que explica los eventos, excepciones y yerros propias al software que está diseñando. Eventos En Java, los eventos representan toda la actividad que tiene espacio entre el usuario y la aplicación. Abstract Windowing Toolkit (AWT) comunica estas acciones a los proyectos de uso de eventos. Cuando el usuario interactúa con un proyecto digamos haciendo clic en un botón de comando, el sistema crea un evento que representa la acción y delega en el código de control de eventos dentro del proyecto. Este código decide la manera de controlar el evento por lo que el usuario obtiene la respuesta adecuada. Existen varios grupos de eventos comunes en proyectos creados en Java, como pueden ser: Eventos de la ventana Eventos del teclado Eventos del ratón Eventos de las barras de desplazamiento Para que un evento logre realizar la acción para la cual se le programo, es indispensable tener un escuchador que este al zarcillo de las acciones del usuario, y este responda inmediatamente de cierta forma. Como todo programa que incluye una interfaz gráfica como eventos de mi programa tendré una ventana que responderá a los botones de la esquina sobresaliente y marcan el cierre o la acción de minimizar la ventana. Como en mi proyecto se requiere que el usuario llene algunos campos se tiene que tener un escuchador para el teclado, que este recibiendo datos del teclado. Y el escuchador para los botones de la ventana principal, también necesita del escuchador. Estos será los eventos que tendría tomados en cuenta en mi programa. Excepciones Una excepción es un evento, que se produce mientras la ejecución de un programa, que interrumpe el flujo usual de las instrucciones del programa. Cuando se produce un yerro dentro de un método, el método crea un objeto y lo entrega al sistema en el tiempo de ejecución. El objeto, llamado un Objeto de Excepción, contiene información sobre el yerro, incluyendo su tipo y el estado del proyecto cuando se produjo el yerro. A la creación de un objeto de excepción y la entrega al sistema en el tiempo de ejecución se designa una excepción. El sistema de ejecución busca en la pila de llamadas de un método que contiene un bloque de código que puede controlar la excepción. Este bloque de código que se llama un controlador de excepciones. La búsqueda se comienza con el método en el que se produjo el yerro y procede a través de la pila de llamadas en el orden inverso en el que los métodos fueron llamados. Existen tres tipos de excepciones El primer tipo de excepción es la excepción comprobada. Estas son cláusulas excepcionales que una aplicación bien escrita debe anticipar y recuperarse. Por ejemplo, si se le pide al usuario indicar el nombre de un archivo que se quiere abrir, y se comete un yerro en la escritura del archivo y este no existe, entonces el proyecto deberá arrojar un anuncio de yerro en la escritura del nombre del archivo. El segundo tipo de excepción es el error. Estas son cláusulas excepcionales que son externos a la demanda, y que la aplicación por lo común no puede anticipar o recuperarse. Por ejemplo, si es indispensable abrir un archivo para que el proyecto haga alguna acción y por fallas en el sistema o hardware este archivo no se puede abrir, estaríamos enfrentando este tipo de error. El tercer tipo de excepción es la excepción en tiempo de ejecución. Estas son cláusulas excepcionales que son internos a la demanda, y que la aplicación por lo común no puede anticipar o recuperarse. Estos por lo común indican yerros de programación, tales como yerros de lógica o el uso indebido de una API. El primer paso en la construcción de un controlador de excepciones es encerrar el código que podría arrojar una excepción dentro de un try. Para asociar controladores de excepciones con try al proporcionar una o más bloques catch inmediatamente después de la try de bloque. Ningún código puede estar entre el final de las try de bloque y el principio de la primera catch de bloque try { catch (ExceptionType name) { catch (ExceptionType name) { Yerros EL yerro es un tipo de excepción que no se puede anticipar y por lo común finaliza cerrando el proyecto. Lo ideal es avisar al usuario que se deberá cerrar el proyecto por completo, y eludir que el proyecto se cierre frente a los ojos del usuario sin darle anterior aviso. En mi caso, si al abrir el proyecto se detecta un yerro que impide abrir correctamente el proyecto, este deberá cerrarse inmediatamente. También se puede esperar a que en el momento de la ejecución del proyecto un evento deje de oir las peticiones por falla en el sistema mismo, este deberá mandar el yerro y avisar del cierre siguiente del proyecto.