lunes
may062013
Pregunta sobre excepciones
jcarmonaloechesTenemos dos códigos: se pide en cada uno de ellos, decir si compila, y en tal caso, comentar la salida en tiempo de ejecución (lo más detallada posible).
CÓDIGO 1
package scjp;
public class Pregunta {
private int a = 0;
private int b = 10;
private int c = b / a;
public Pregunta() {
System.out.println("Hola JavaHispaneros "+c);
}
public static void main(String args[]) {
Pregunta p = new Pregunta();
}
}
package scjp;
public class Pregunta {
private int a = 0; private int b = 10; private int c = b / a;
public Pregunta() { System.out.println("Hola JavaHispaneros "+c); }
public static void main(String args[]) { Pregunta p = new Pregunta();
}}
CÓDIGO 2
package scjp;
public class Pregunta { private D d = new D(); public Pregunta() { System.out.println("Por aquí estamos otra vez " + d); } public static void main(String args[]) { Pregunta p = new Pregunta(); } class D { D() throws PersonalException { throw new PersonalException(); } } class PersonalException extends Exception { } }
Reader Comments (6)
Primer.
El primer código compilará sin problemas, pero lanzará una excepción al ejecutarse. Concretamente al instanciar la clase Pregunta, ya que es en ese momento cuando se evalua "b/a" (y a es cero)
El segundo código no compilará, ya que el constructor de D lanza una excepción "checked", y se está utilizando en la declaración del atributo "d" de Pregunta.
Para que compile, hay que declarar que el constructor de Pregunta lance una PersonalException (sí, aunque no se haga explícitamente ahí la asignación), y por supuesto, declararla también en el main.
Ok, la respuesta es correcta @adeteran.
Mi pregunta es: ¿qué entiendes exactamente por excepciones "checked"?
Las que estás obligado a declarar en el método, cuando pueden ser lanzadas ¿no?.
A efectos prácticos, todas las Exception (y descendientes) que no son RuntimeException (y descendientes). O si queremos ser más completos, y añadir todo lo lanzable, sería "checked" la clase Throwable y sus descendientes, pero no lo serían las clases Error y RuntimeException, y sus respectivos descendientes ("unchecked").
Si PersonalException heredara de RuntimeException, el código compilaría tal y como está.
Buen punto de vista @adeteran. Veo muy práctico el consejo de "aquellas excepciones que son definidas en tiempo de desarrollo y especificadas". Al fin y al cabo, son las que se pueden controlar.
Mi pregunta es, ¿por qué Java tiene la limitación de no saber reaccionar a una división entre cero?
Java sí reacciona ante una división por cero. El mayor problema lo tienen los enteros, porque lanza una excepción.
Se puede usar un bloque try..catch en estos casos:
En los casos de double y float, el resultado es un INFINITY
http://docs.oracle.com/javase/7/docs/api/java/lang/Double.html
http://docs.oracle.com/javase/7/docs/api/java/lang/Float.html
int divisor = 0;
try {
int dividendo = 10 / divisor
} catch (ArithmeticException ex) {
System.out.println("División por cero.");
}
Para más información:
http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.17.2
Hola @choces, gracias por el punto de vista.
Más bien lo que quería decir es que Java permite definir el siguiente código:
int divisor = 0;
int dividendo = 10 / divisor;
sin necesidad de detectar que aquí es necesaria una comprobación de excepción aritmética. Es decir, en tiempo de compilación, no es capaz de preever este problema (si en tiempo de ejecución).
Esto es lo que @adeteran define como excepción no "chequeada" (sólo es capaz de verla en tiempo de ejecución, al no estar especificada como tal, no es capaz de obligar a definirla en tiempo de compilación, lo que obliga a tener la posibilidad de fallo).
Los creadores de Java podrían, en este caso, haber determinado por norma que cualquier división pudiera lanzar esta excepción, pero es que, si nos fijamos, la división no es una operación de clases, si no de operadores aritméticos normales. Es decir, escapa de la programación orientada a objetos, que si permite definir excepciones ante métodos que se preveen que puedan lanzarla.
Es la explicación que, a día de hoy, puedo entender.
Un saludo,