2009-08-11 13 views
24

Por lo que yo entiendo, no hay forma de descubrir qué excepciones arroja un método sin consultar los documentos API uno a uno.¿Excepciones de Java más comunes marcadas y no comprobadas?

Dado que es otra opción, me gustaría invertir la investigación y preguntará qué son las excepciones y RuntimeExceptions más comunes que he encontrado cuando se trata de:

  • casting
  • matrices
  • Vector, ArrayList, HashMap, etc.
  • IO (clase File, arroyos, filtros, ...)
  • serialización de objetos
  • Hilos (wait(), dormir(), etc.)
  • o cualquier otra cosa que se considera "Java básico"

Soy consciente de que esto podría ser subjetiva y aburrido, pero es para una prueba de clase y Realmente no lo sé mejor

+1

No es realmente cierto para las excepciones marcadas, un método define qué excepciones puede arrojar. Para todos los demás (como NPE), bueno, hay una razón por la que no están marcados. – Gandalf

+0

Puede usar BCEL o ASM para analizar los binarios y repetir el código en cada método para encontrar su respuesta. –

Respuesta

30

asumir la continuación son java.lang a menos que se especifique lo contrario:

  • casting: ClassCastException
  • matrices: ArrayIndexOutOfBoundsException, NullPointerException
  • Colecciones: NullPointerExcep ción, ClassCastException (si no se está usando autoboxing y meter la pata)
  • IO: java.io.IOException, java.io.FileNotFoundException, java.io.EOFException
  • serialización: java. io.ObjectStreamException (y sus subclases, que estoy demasiado perezoso para enumerar)
  • Hilos: InterruptedException, SecurityException, IllegalThreadStateException
  • Potencialmente común a todas las situaciones: NullPointerException, IllegalArgumentException

Usted haría Haga bien en mirar las páginas de resumen de paquetes del sitio de Java. Aquí hay uno: http://java.sun.com/j2se/1.4.2/docs/api/java/io/package-summary.html

+0

Nunca me di cuenta de que hay un "Resumen de excepciones" ahí abajo. ¡Gracias! –

+0

(Editado para hacer legible la lista de excepciones) No hay problema, acabo de descubrirlo yo solo por accidente. Qué bueno es que "cuando uno enseña, dos aprenden", ¿eh? Lo siento por ser un poco raro antes, voy a editar para solucionarlo en breve. –

+0

Hola, acabo de probar el enlace publicado anteriormente en el resumen del paquete, no se resuelve, ¿alguien sabe la nueva ubicación? – Sizons

15

NullPointerException

+2

Quizás la mejor respuesta de una sola palabra en SO. – Azim

1

Las excepciones comprobadas son fáciles, el editor debería mostrar los javadocs cuando se pasa/completar el nombre del método.

Desmarcados generalmente son errores reales y ni siquiera están en los javadocs más de las veces. Supongo que la más común podría ser IllegalArgumentException, cualquier método que tenga una combinación posible de parámetros que no sea válido debería lanzarlo.

+0

Si está usando un editor de texto, no mostrará necesariamente javadocs en la finalización del nombre del método. :-( –

+0

Creo que te refieres a IllegalArgumentException. –

+4

No uses un editor de texto. (Créeme, lo hice por décadas). Es como dejar que el aire de tu bicicleta se caiga porque necesitas más ejercicio. –

1

¿Qué tal en busca de subclases de java.lang.Exception, por ejemplo here

Personalmente utilizo 2 excepciones comprobadas de mi propia TransientException para los casos en que un reintento podría funcionar. Y InvalidRequestException para errores de validación.

3

Como Bill K dice. Las excepciones comprobadas son fáciles. Si su IDE/editor de programa no le proporciona una forma rápida de ver el método javadocs o las firmas, debe desecharlo. Seriamente.

excepciones no comprobadas son harina de otro costal. Pero creo que la mejor estrategia con excepciones no revisadas es no intentar atraparlas. En cambio, escribes tu código para que evite tirarlos en primer lugar. Por ejemplo;

// ... not sure if 'obj' is null 
if (obj != null) { 
    obj.someMethod(); 
} 
// ... not sure if 'obj' has the right type 
if (obj instanceof Foo) { 
    Foo foo = (Foo) obj; 
} 
// ... not sure if 'i' is in range 
if (i >= 0 && i < array.length) { 
    .... = array[i]; 
} 

Aquí es por lo que recomiendo esto:

  • Una prueba de guardia es órdenes de magnitud más eficientes que lanzar y atrapar una excepción.
  • Una prueba de guardia es más fácil de leer ... menos líneas de código.
  • Si se coge una excepción sin control, nunca se puede estar seguro de que ha pasado por las razones que usted piensa que lo hizo; por ejemplo:
 
    // obj might be null ... 
    try { 
     obj.doSomething(); 
    } catch (NullPointerException ex) { 
     System.err.println("obj was null"); // WRONG!!! 
     // the NPE could have happen inside doSomething() 
    } 
  • Si una excepción sin control se debe a un error, te quiero un StackTrace y (dependiendo de la aplicación) puede que no desee recuperar.

Obviamente, solo incluye estos controles de "guardia" donde su comprensión del código indica que son necesarios. Así, por ejemplo, si sabe que 'obj' debe ser no nulo y 'i' debería estar en el rango, es una buena idea dejar los cheques. Si omites demasiadas pruebas, obtendrás una excepción ... pero eso es bueno porque puedes usar la stacktrace para descubrir por qué tu comprensión del código era incorrecta y quizás arreglar el error subyacente.

+0

Respuesta muy completa. –

7

java.lang:

  1. ArithmeticException
  2. ArrayIndexOutOfBoundsException
  3. ClassCastException
  4. ClassNotFoundException
  5. CloneNotSupportedException
  6. IllegalArgumentExcepion
  7. IllegalMonitorStateException
  8. IllegalThreadStateExc eption
  9. IndexOutOfBoundsException
  10. InterruptedException
  11. NullPointerException
  12. NumberFormatedException

java.util:

  1. ConcurrentModificationException

java.io:

  1. EOFException
  2. FileNotFoundException
  3. IOException
  4. NotSerializableException
0
  • Fundición - ClassCastException

  • matrices - ArrayIndexOutOfBoundsException

  • Vector, ArrayList, HashMap, etc - que rara vez ver excepciones cuando se trabaja con colecciones de Java, pero muy de vez en cuando ConcurrentModificationException

  • IO (clase File, arroyos, filtros, ...) - FileNotFoundException

  • serialización de objetos - ClassNotFoundException

  • Hilos (wait(), dormir(), etc.) - En mi experie Por lo general, los problemas de enhebrado se manifiestan de formas aleatorias que no son específicas de una excepción. Tener que lidiar con InterruptedException ocupa mucho tiempo, aunque no he visto la excepción realmente lanzada mucho.

  • o cualquier otra cosa que se considere "Java básica" - de lejos la excepción más común en mi experiencia es NullPointerException.

11

lista de excepciones sin control
ArrayIndexOutOfBoundsException
ClassCastException
IllegalArgumentException
IllegalStateException
NullPointerException
NumberFormatException
AssertionError
ExceptionInInitializerError
StackOverflowError
NoClassDefFoundError

Lista excepción comprobada
Excepción
IOException
FileNotFoundException
ParseException
ClassNotFoundException
CloneNotSupportedException
InstantiationException
InterruptedException
NoSuchMethodException NoSuchFieldException

Cuestiones relacionadas