Quelle est l'utilisation prévue de IllegalStateException?

Question

Cela est arrivé lors d'une discussion avec un collègue aujourd'hui.

La Javadoc de Java IllegalStateException état de:

Les signaux qu'une méthode a été appelée à une illégales ou inappropriées temps. En d'autres termes, l'environnement Java ou Java application n'est pas dans un état approprié à l'opération demandée.

Et Efficace Java indique (Article 60, page 248):

Un autre souvent réutilisés exception IllegalStateException. C'est généralement à l'exception de jeter si l'invocation est illégale en raison de l'état de l'objet récepteur. Par exemple, ce serait l'exception à jeter si l'appelant a tenté d'utiliser un objet avant qu'il ait été correctement initialisé.

Il semble qu'il ya un peu de différence ici. La deuxième phrase de la javadoc le fait ressembler à l'exception peut décrire une très large condition sur le Java état de l'exécution, mais la description Effective de Java fait sonner comme il est utilisé dans des conditions particulièrement liée à l'état de l'état de l'objet dont la méthode a été appelée.

Les usages que j'ai vu dans le JDK (par exemple, les collections, Matcher) et dans la Goyave certainement l'impression de tomber dans la catégorie que l'efficacité de Java parle ("Cet objet est dans un état où cette méthode ne peut pas être appelé"). Cela semble également compatible avec IllegalStateException's de la fratrie IllegalArgumentException.

Sont-il légitime IllegalStateException usages dans le JDK qui ne se rapportent à la "environnement Java" ou "Java application"? Ou faire des guides sur les pratiques exemplaires défenseur de l'utiliser pour l'ensemble de l'état de l'exécution? Si non, pourquoi diable sont les javadocs formulé comme ça? ;)

Answer 1

Ici est un particulier de l'usage légitime de cette exception dans le JDK (voir: URLConnection.setIfModifiedSince(long) parmi les 300+ d'autres usages:

public void setIfModifiedSince(long ifmodifiedsince) {
    if (connected)
        throw new IllegalStateException("Already connected");
    ifModifiedSince = ifmodifiedsince;
}

Je pense que l'exemple est assez clair. Si l'objet est dans l'état particulier ("Déjà connecté"), certaines opérations ne devraient pas être appelée. Dans ce cas, lorsque la connexion a été établie, certaines propriétés ne peuvent pas être ensemble.

Cette exception est particulièrement utile lorsque votre catégorie a de l'état (l'état de la machine?) que les changements au fil du temps, ce qui rend certaines méthodes non pertinents ou impossible. Que penser d'un Car classe start(), stop() et fuel() méthodes. Tout en appelant start() deux fois, l'une après l'autre, n'est probablement rien de mal, mais ce qui alimente un a commencé voiture est certainement une mauvaise idée. À savoir: - la voiture est dans un mauvais état.

Sans doute bon de l'API ne doit pas nous permettre de faire appel à des méthodes en mauvais état, de sorte que de tels problèmes sont découverts au moment de la compilation, et non pas au moment de l'exécution. Dans cet exemple, se connecter à une URL doit retourner un objet différent avec un sous-ensemble de méthodes, qui sont toutes valables après la connexion.

Answer 2

Voici un exemple dans le JDK. Il y a un paquet de classe privée appelée java.lang.De l'arrêt. Si le système s'arrête et que vous essayez d'ajouter un nouveau crochet, il lève l'exception IllegalStateException. On pourrait dire que c'répond aux critères de la "javadoc" orientation - puisque c'est l'environnement Java est dans le mauvais état.

class Shutdown {    
...

   /* Add a new shutdown hook.  Checks the shutdown state and the hook itself,
    * but does not do any security checks.
    */
    static void add(int slot, Runnable hook) {
        synchronized (lock) {
            if (state > RUNNING)
                throw new IllegalStateException("Shutdown in progress");

            if (hooks[slot] != null)
                throw new InternalError("Shutdown hook at slot " + slot + " already registered");

            hooks[slot] = hook;
        }
    }

Cependant, il illustre également le fait qu'il n'y a vraiment pas de distinction entre le "javadoc" orientation et de la "Effective Java" de l'orientation. En raison de la façon dont l'Arrêt est mis en œuvre, la mise à l'arrêt " de la JVM est stockée dans un champ appelé de l'état. Par conséquent, il répond également aux "Effective Java" pour savoir quand utiliser IllegalStateException, depuis le champ "etat" fait partie de l'état de l'objet récepteur. Depuis la réception de l'objet (Arrêt) est en mauvais état, il lève l'exception IllegalStateException.

À mon avis, les deux descriptions de cas d'utilisation d'exception IllegalStateException sont cohérentes. L'efficacité de Java description est un peu plus pratique, c'est tout. Pour la plupart d'entre nous, la partie la plus importante de l'ensemble de l'environnement Java est la classe que nous écrivons en ce moment, donc c'est ce que l'auteur se concentre sur.

Answer 3

Je suppose que si vous voyez l'utilisation de IllegalStateException je dirais deuxième cas échéant. Cette exception est utilisé dans beaucoup de paquets

• java.net
• java.nio
• java.util
• java.util.concurrrent etc

Pour spécifier un exemple ArrayBlockingQueue.ajouter lève cette exception si la file d'attente est déjà pleine. Maintenant plein est de l'état de l'objet et elle est appelée à inappropriée ou Illégale de temps

Je suppose que les deux moyens-même, mais la différence de libellé.

Answer 4

Il n'y a pas de «divergence» ici. Le libellé de Bloch n’exclut pas ce qui est écrit dans le JLS. Bloch dit simplement que si vous avez la circonstance A, lancez cette exception. Il ne dit pas que cette exception est / devrait être levée uniquement dans cet état. Le JLS dit que cette exception est levée si A, B ou C.

Answer 5

J'ai rencontré ceci avec:

 try {
    MessageDigest digest = MessageDigest.getInstance("SHA-1");
    ...
} catch (NoSuchAlgorithmException e) {
    throw new AssertionError(e);
}
 

Je pense qu'il ne sera pas pratique pour moi de jeter IllegalStateException ici à la place de AssertionException même si cela tombe dans la catégorie "de l'environnement Java".