Tres tipos de excepciones en Java

Los errores son la ruina de los usuarios y programadores por igual. Los desarrolladores obviamente no quieren que sus programas se caigan a cada paso y los usuarios ahora están tan acostumbrados a tener errores en programas que a regañadientes aceptan pagar el precio del software que casi seguro tendrá al menos un error en eso. Java está diseñado para brindarle al programador una oportunidad deportiva de diseñar una aplicación sin errores. Hay excepciones que el programador sabrá que son una posibilidad cuando una aplicación interactúa con un recurso o un usuario y estas excepciones pueden ser manejadas. Desafortunadamente, hay excepciones que el programador no puede controlar o simplemente pasa por alto. En resumen, todas las excepciones no son iguales y, por lo tanto, hay varios tipos en los que un programador debe pensar.

Una excepción es un evento que hace que el programa no pueda fluir en su ejecución prevista. Hay tres tipos de excepción: la excepción marcada, el error y la excepción de tiempo de ejecución.

Las excepciones marcadas son excepciones que una aplicación Java debería poder hacer frente. Por ejemplo, si una aplicación lee datos de un archivo, debería poder manejar FileNotFoundException. Después de todo, no hay garantía de que el archivo esperado vaya a estar donde se supone que debe estar. Cualquier cosa podría suceder en el sistema de archivos, del cual una aplicación no tendría idea.

Para llevar este ejemplo un paso más allá. Digamos que estamos usando el FileReader clase para leer un archivo de caracteres. Si echas un vistazo a la Definición del constructor FileReader en la API de Java verá su firma de método:

Public FileReader (String fileName) lanza FileNotFoundException.

Como puede ver, el constructor declara específicamente que el FileReader el constructor puede lanzar un FileNotFoundException. Esto tiene sentido ya que es muy probable que el nombre del archivo La cadena será incorrecta de vez en cuando. Mira el siguiente código:

public static void main (String [] args) { FileReader fileInput = null; // Abre el archivo de entrada. fileInput = new FileReader ("Untitled.txt"); }

Sintácticamente las declaraciones son correctas, pero este código nunca se compilará. El compilador conoce el FileReader el constructor puede lanzar un FileNotFoundException y depende del código de llamada manejar esta excepción. Hay dos opciones: en primer lugar, podemos pasar la excepción de nuestro método especificando un tiros cláusula también:

public static void main (String [] args) lanza FileNotFoundException { FileReader fileInput = null; // Abre el archivo de entrada. fileInput = new FileReader ("Untitled.txt"); }

O en realidad podemos manejar con la excepción:

public static void main (String [] args) { FileReader fileInput = null; tratar. { // Abre el archivo de entrada. fileInput = new FileReader ("Untitled.txt"); } catch (FileNotFoundException ex) { // dile al usuario que vaya y busque el archivo. } }

Las aplicaciones Java bien escritas deberían poder hacer frente a las excepciones comprobadas.

El segundo tipo de excepción se conoce como error. Cuando ocurre una excepción, el JVM creará un objeto de excepción. Todos estos objetos derivan de la Tirable clase. los Tirable la clase tiene dos subclases principales: Error y Excepción. los Error La clase denota una excepción que no es probable que una aplicación pueda manejar.

Estas excepciones se consideran raras. Por ejemplo, la JVM podría quedarse sin recursos debido a que el hardware no puede hacer frente a todos los procesos con los que tiene que lidiar. Es posible que la aplicación detecte el error para notificar al usuario, pero generalmente la aplicación tendrá que cerrarse hasta que se resuelva el problema subyacente.

UN excepción en tiempo de ejecución ocurre simplemente porque el programador ha cometido un error. Ha escrito el código, todo se ve bien para el compilador y cuando va a ejecutar el código, se cae porque intentó acceder a un elemento de una matriz que no existe o un error lógico provocó que se llamara a un método con un valor nulo valor. O cualquier cantidad de errores que pueda cometer un programador. Pero está bien, detectamos estas excepciones mediante pruebas exhaustivas, ¿verdad?

Los errores y las excepciones de tiempo de ejecución entran en la categoría de excepciones no verificadas.