Title: OCR Document
Author: Readiris
Company: I.R.I.S.

Creación de tipos de excepción

Las excepciones son objetos. Todos los tipos de excepción (es decir, cualquier clase diseñada para objetos lanzables) debe extender la clase Throwable o una de sus subclases. La clase Throwable contiene una cadena de texto que se puede utilizar para describir la excepción. Por convenio, los nuevos tipos de excepción extienden a Exception, una subclase de Throwable.

Las excepciones son principalmente excepciones comprobadas, lo que significa que el COffipilador comprueba que nuestros métodos lanzan sólo las excepciones que ellos mismos han declarado que pueden lanzar. Las excepciones y errores estándar en tiempo de ejecución extienden una de las clases RuntimeException o Error, y se denominan excepciones no comprobadas. Todas las excepciones que creemos deberían extender a Exception, siendo así excepciones comprobadas.

Las excepciones comprobadas representan condiciones que, aunque excepcionales, se puede esperar razonablemente que ocurran, y si ocurren deben ser consideradas de alguna forma. Al hacer que estas excepciones sean comprobadas se documenta la existencia de la excepción y se asegura que el que llama a un método tratará la excepción de alguna forma. Las excepciones no comprobadas representan condiciones que, hablando en términos generales, reflejan errores en la lógica de nuestro programa de los que no es posible recuperarse de forma razonable en ejecución. Por ejemplo, una excepción IndexOutOfBoundsException que se lanza al intentar acceder fuera de los límites de un array, nos indica que nuestro programa calcula los índices de forma incorrecta, o que falla al verificar un valor que se va a utilizar como índice. Estos errores deben corregirse en el código del programa. Como pueden producirse errores al escribir cualquier sentencia, sería totalmente imposible tener que declarar y capturar todas las excepciones que podrían surgir de estos errores, de ahí la existencia de las excepciones no comprobadas.
Algunas veces es útil tener más datos para descríbir la condición excepcional, además de la cadena de texto que proporciona Exception. En esos casos se puede extender a Exception creando una clase que contenga los datos añadidos (que generalmente se establecen en el constructor).

Por ejemplo, supongamos que se añade un método susti tuirValor a la interfaz Atribuido que se presentó en el Capítulo 4. Este método sustituye el valor actual de un atributo con nombre por un nuevo valor. Si dicho atributo con nombre no existe, se debería lanzar una excepción, ya que es razonable suponer que sólo se pueden sustituir atributos existentes. Esa excepción debería contener el nombre del atributo. Para representar la excepción, creamos la clase NoTalAtributoException:

8.2.2 Excepciones asíncronas

Una sentencia throw produce una excepción síncrona, como también por ejemplo, la excepción aritmética resultado de la división por cero. La excepción se produce directamente como resultado de ejecutar una instrucción particular: o bien throw o bien la división por cero. Por el contrario, una excepción asíncrona es aquella que se puede producir en cualquier momento, independientemente de la instrucción que se está ejecutando.

Las excepciones asíncronas pueden ocurrir sólo de dos formas específicas. La primera es un error interno de la máquina virtual de Java. Estas excepciones se consideran asíncronas porque son causadas por la ejecución de instrucciones de la máquina virtual, no de las instrucciones del programa. No es necesario decir que hay poco que podamos hacer si se produce un error interno.

El segundo mecanismo es el uso de los desaprobados métodos Thread. stop, o de los no desaprobados métodos relacionados stopThread de la JavaTM Virtual Machine Debug Inteiface (Interfaz de Depuración de la Máquina Virtual de Java™, JVMDI), una interfaz de la máquina virtual en código nativo que permite la inspección y el control de una aplicación en ejecución. Estos métodos permiten lanzar una excepción asíncrona de cualquier clase (comprobada o no comprobada) en cualquier punto de la ejecución del hilo sobre el que actúan. Este mecanismo es intrínsecamente peligroso, por lo que han sido desaprobado s en la clase Thread. Volveremos sobre este punto en el Capítulo 10.