2009-04-03 8 views
2

Imaginez que j'ai les méthodes:exception java question enchaînant

public static void funcA() {...} 

public static void funcB() 
{ 
    byteBuffer.wrap(someByteArray, 0, someByteArra.length); 
} 

API JAVA:

public static ByteBuffer wrap(byte[]array, int offset, int length) 
{ 
    try { 
     return new HeapByteBuffer(array, offset, length); 
    } catch (IllegalArgumentException x) { 
     throw new IndexOutOfBoundsException(); 
    } 
} 
chaîne de fonctions

: FoncB() -> ByteBuffer.wrap()

Ma question est comment venir funcB n'a pas besoin de faire un bloc try-catch autour de cette méthode java api qui déclenche une exception. funcB compile bien sans un bloc try-catch. Je crois que la réponse a à voir avec le fait que la méthode java api jette une exception MAIS N'EST PAS DÉCLARÉE comme "throws IndexOutOfBoundsException"

chaîne de fonction: funcA() -> funcB() -> ByteBuffer.wrap (..

Ma prochaine question est quand je DO changer funcB à "funcB() throws IndexOutOfBoundsException" pourquoi funcA n'a pas besoin d'attraper l'exception levée de funcB? Est-ce que le compilateur creuse profondément et se rend compte que ByteBuffer.wrap (...) n'est pas déclaré comme "wrap() throws IndexOutOfBoundsException" de sorte que tous les appelants n'ont pas réellement besoin d'attraper quoi que ce soit même les sous-appelants (funcB dans ce cas) sont déclarés comme "funcB throws IndexOutOfBoundsException"? Désolé, si c'était confus ou difficile à comprendre.

Aidez-nous s'il vous plaît.

JBU

Répondre

9

IndexOutofBoundsException étend RuntimeException. C'est une exception d'exécution, n'a pas besoin d'être vérifiée.

Voir unchecked exceptions - the controversy.

+0

alors à quoi bon jeter des clauses s'il y a des exceptions qui n'ont pas besoin d'être interceptées? – jbu

+0

Parfois, vous voulez l'OPTION d'attraper l'exception sans avoir à le repousser explicitement. –

+0

Ah, ce serait une bonne option. Je peux le voir mener à la paresse cependant. – jbu

4

Au sommet de la hiérarchie des exceptions est java.lang.Throwable. C'est une exception vérifiée (le compilateur vous oblige à l'attraper ou à déclarer que vous l'avez lancé). Ci-dessous Throwable il y a Exception, également une exception vérifiée, et Error, une exception non cochée (le compilateur ne vous avertit pas à ce sujet)

En dessous de Exception, RuntimeException existe, également une exception non contrôlée.

La façon dont les concepteurs de Java destinés exceptions à utiliser est:

  • Exception, les choses qui peuvent mal tourner
  • erreur, les choses de bas niveau qui peuvent mal tourner et un programme ne peut pas récupérer de
  • RuntimeException, erreurs de programmeur (comme dépasser la fin d'un tableau, ou appeler une méthode sur null).

L'idée derrière ne pas avoir à prendre des exceptions non contrôlées est qu'ils indiquent les défaillances (niveau VM, ou programmeur) qui soit vous ne pouvez pas gérer (erreur VM) ou ne devrait pas exister dans une (erreur de programmation) du programme débogué correctement.

Tout le monde n'est pas d'accord avec l'intention des concepteurs de Java sur ce point et a choisi d'utiliser RuntimeException pour désigner d'autres choses que des erreurs de programmation.