La generación de excepciones (y errores) es muy simple. Una vez detectada la situación excepcional puede activarse el mecanismo instanciando un objeto de la clase "arrojable" que se considere adecuada, introduciendo en ella la información precisa y utilizando:

Lo más normal será que no introduzcamos ninguna información específica ya que por defecto, al heredar comportamiento de sus superclases, la información incluida automáticamente puede ser suficiente. De este modo puede ser adecuado escribir algo como lo siguiente en caso de que se produzca un error en un tratamiento propio de datos de entrada/salida:

 1-

if (condición_de_error) throw new IOException();

En este ejemplo se ha construido el objeto arrojable sin parámetros. Existe otro constructor que admite una String que tambien es utilizado comunmente:

 1-

if (condición_de_error) throw new IOException("Rebasado límite autorizado en salida");

Una vez que se ejecuta el throw se aborta la ejecución del código, de modo que si se encontraba dentro de un bloque try pasará a ejecutarse el correspondiente catch. De no ser así, terminará el método y este "arrojará" el objeto "hacia" la rutina que llamó a esta.

Cuando un método deja "escapar" objetos arrojables es preciso que se indique en su construcción, para lo que basta con añadir a su prototipo, despues de los parámetros la papabra reservada throws y la lista, separada con comas, de todas aquellas clases de las que puede lanzar objetos. P.ej:

 1-
 2-
 3-

public void desahogada() throws IOException, NumberFormatException, ArithmeticException { 
  //cuerpo del método, donde se producen y no se atienden las excepciones indicadas.
}

Por tanto, ante las situaciones en que puedan producirse excepciones (o errores) en cada caso tendremos que plantearnos qué será lo adecuado, si atenderlas en un bloque catch o dejarlas salir del método declarandolo explícitamente. Esto es así para toda situación de excepción en la que el compilador nos obliga a tomar una determinación, pero no sucede esto para todas. El compilador permite que algunas excepciones no sean tratadas ya que se entiende que obedecen a situaciones que el programador ha podido evitar (por ejemplo ArithmeticException puede darse en una división de enteros cuando el denominador es cero, pero puede que el algoritmo no permita esta situación, por lo que no es razonable obligar a "controlarla").

Sobreescritura de métodos que arrojan excepciones o errores

En una clase que hereda de otra, puede sobreescribirse un método que en la clase padre arrojaba excepciones variando el comportamiento al respecto, pero sólo en el sentido de hacerla más restrictiva, es decir tratando internamente ciertas excepciones que el método de la clase padre no trataba. El siguiente ejemplo muestra esto: el método metodo de la clase B sobreescribe al de la clase A, pero es más restrictivo en su emisión de excepciones ya que solo puede "dejar escapar" las de tipo FileNotFoundException que es una clase particular de las que el método sobreescrito podia emitir dentro del grupo de las IOException.

1-
2-
3-
4-
5-
6-
7-
8-
9-
10-
11-
12-
13-
14-
15-

import java.io.*;
import java.text.*;

public class A {

    public void metodo() throws IOException, ParseException {
        // ...
	int i=f.read(); //IOException no atendida
        //...
	Double d=df.parse(s); //ParseException no atendida
        //...
    }

    //....
}

1-
2-
3-
4-
5-
6-
7-
8-
9-
10-
11-
12-

import java.io.*;

public class B extends A{

    public void metodo() throws FileNotFoundException {
        // ...
	FileInputStream f=new FileInputStream();
        //...
    }

    //....
}