Quelle est l'utilisation prévue de l'exception IllegalStateException?

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

La Javadoc de Java IllegalStateException état:

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 IllegalStateExceptions'frère 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? 😉

  • Sur un peut-être sans rapport, note, j'ai remarqué StackOverflow est [illegalstatexception] tag dit In Java, an exception that occurs when using multiple threads, whereby one thread modifies an object in a way that makes it incompatible with the use of that object in the second thread, thus putting the object into an illegal state.. Hein? D'où vient-il?
  • Le "Java application" est celui de vous écrire, et vous pouvez les utiliser IllegalStateException il (soit directement, soit parce que vous êtes à l'aide de Goyave, par exemple). Où est la différence?
  • La balise wiki semble faux, j'ai soumis une édition généreusement par l'emprunt à partir de cette question; vous devriez voir la nouvelle version une fois qu'il a passé l'examen par les pairs.
InformationsquelleAutor Andrew McNamee | 2012-10-02
  1. 40

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

    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 qui a 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.

    • Je suis d'accord avec votre réponse. Mais cela n'explique pas pourquoi Effectiva Java et Goyave utilise cette Exception comme une IllegalArgumentException
    InformationsquelleAutor Tomasz Nurkiewicz
  2. 4

    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.

    • Ah, j'aime bien cet exemple! Le InternalError jette juste en dessous de l'ISE montre également combien il est utile de faire un "Vous foiré" vs "j'ai foiré" distinction. Aussi, il montre comment l'état statique (on pourrait dire "Java Application" ou "Java Environnement" de l'état), vaut de l'état autant que ISEs sont concernés.
    • Je pense que AssertionError serait plus approprié pour les cas où je sais que j'ai foiré. Il semble être un InternalError seulement parce qu'il est à l'intérieur de JDK code plutôt que le code de l'application - une distinction douteuse.
    • Yep, je suis certainement d'accord sur AssertionError; il semble véhiculer "j'ai foiré" par opposition à "Vous foiré" (qui ISE implique). Je l'utilise beaucoup dans le default cas pour switches. OMI InternalError toujours une fin utile, la personne la lecture de la trace de pile sait qu'ils peuvent assumer "Whoa, le JDK foiré", mais le JDK auteurs pourraient probablement avoir laissée.
    InformationsquelleAutor Guido Simone
  3. 2

    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é.

    InformationsquelleAutor Amit Deshpande
  4. 1

    Donné une bibliothèque, il faut jeter un IllegalStateException ou IllegalArgumentException chaque fois qu'il détecte un bug dû à l'utilisateur de code, tandis que la bibliothèque devrait lancer une AssertionError chaque fois qu'il détecte un bug dû à la bibliothèque de la mise en œuvre.

    Par exemple, dans la bibliothèque de tests, vous pouvez vous attendre à la bibliothèque jette un IllegalStateException lorsque l'ordre des appels de méthode sont mauvais. Mais vous n'attendez jamais de la bibliothèque jette un AssertionError.

    InformationsquelleAutor Yang Bo
  5. 0

    Il n'y a pas de "différence" ici. Il n'y a rien de Bloch du libellé qui exclut ce qu'il dit dans le JLS. Bloch est tout simplement dire que si vous avez des circonstances, de se débarrasser de cette exception. Il est pas dire que cette exception est/devrait être jeté seulement dans cette condition. JL dit cette exception est levée si A, B, ou C.

    • Je suppose que vous pourriez dire que. Mais d'un autre côté, si elle avait eu l'intention d'utilisation des circonstances différentes de la circonstance, il a donné, alors la n'est peut être pas significatif car il serait moins spécifiques. En d'autres termes, si ISE étaient destinés à être utilisés dans d'autres circonstances que l'actuel "Vous avez appelé cette méthode sur moi, mais je ne suis pas dans un état où je peux le faire" le cas, il pourrait ne pas être aussi instructif. Mais il est vrai que je pense que je suis le fractionnement des poils ici 😉
    • J' ne dire que. Je ne sais pas ce que le reste de votre commentaire, même moyen, mais vous essayez de fabriquer une contradiction là où il n'en existe aucun. Vous commettez une erreur de logique.
    InformationsquelleAutor user207421
  6. 0

    Je suis tombé sur cette avec:

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

    Je pense que ça va être difficile pour moi de jeter IllegalStateException ici à la place de AssertionException même si cela tombe dans le "la Java de l'environnement" de la catégorie.

    InformationsquelleAutor antak