Aqui está um exemplo simples de como usar a exceção:
class IntegerExceptionTest {
public static void main(String[] args) {
try {
throw new IntegerException(42);
} catch (IntegerException e) {
assert e.getValue() == 42;
}
}
}
O corpo da instrução TRy lança a exceção com um determinado valor, que é capturado pela cláusula catch.
Por outro lado, a seguinte definição de uma nova exceção é proibida, pois cria um tipo parametrizado:
class ParametricException<T> extends Exception { // compile-time error
private final T value;
public ParametricException(T value) { this.value = value; }
public T getValue() { return value; }
}
Uma tentativa de compilar o que foi mencionado acima relata um erro:
% javac ParametricException.java
ParametricException.java:1: a generic class may not extend
java.lang.Throwable
class ParametricException<T> extends Exception { // compile-time error
^
1 error
Essa restrição é sensata porque quase qualquer tentativa de capturar essa exceção deve falhar, porque o tipo não é reificável. Pode-se esperar que um uso típico da exceção seja algo como o seguinte:
class ParametricExceptionTest {
public static void main(String[] args) {
try {
throw new ParametricException<Integer>(42);
} catch (ParametricException<Integer> e) { // compile-time error
assert e.getValue()==42;
}
}
}
Isso não é permitido, porque o tipo na cláusula catch não é reificável. No momento da redação deste artigo, o compilador Sun reporta uma cascata de erros de sintaxe nesse caso:
% javac ParametricExceptionTest.java
ParametricExceptionTest.java:5: <identifier> expected
} catch (ParametricException<Integer> e) {
^
ParametricExceptionTest.java:8: ')' expected
}
^
ParametricExceptionTest.java:9: '}' expected
}
^
3 errors
Como as exceções não podem ser paramétricas, a sintaxe é restrita, de modo que o tipo deve ser gravado como um identificador, sem o seguinte parâmetro.