web-dev-qa-db-fra.com

les exceptions non vérifiées en Java ne peuvent-elles pas être gérées à l'aide du bloc try/catch?

Dans un tutoriel, j'ai constaté que l'exception non cochée ne peut pas être traitée par votre code i.e. Nous ne pouvons pas utiliser le bloc try/catch et les exemples sont des exceptions telles que ArrayIndexOutOfBoundsException, NullPointerException.. Cependant, ces exceptions peuvent être traitées à l'aide du bloc try/catch. Je pense que je ne suis pas clair sur le concept !! 

Aussi, je pense que le mot-clé throw peut être utilisé uniquement avec try/catch block.can throw Le mot-clé est utilisé avec UncheckedException?

javaexceptionexception-handling
20
Aravindh an

La seule différence entre les exceptions cochées et non cochées est que celles-ci cochées ont doivent être capturées ou déclarées dans la signature de la méthode en utilisant throws, alors que pour les non cochées, cela est facultatif.

Votre code ne permet pas de gérer les exceptions non contrôlées, c'est-à-dire que nous ne pouvons pas utiliser le bloc try/catch

Bien sûr que nous pouvons - mais nous ne sommes pas obligés.

De plus, je pense que le mot-clé throw peut être utilisé uniquement avec try/catch block.c. Le mot-clé throw est-il utilisé avec Exception non contrôlée?

Notez qu'il existe deux mots clés:

  • throw lève explicitement un objet exception que vous avez créé. throw new NullPointerException(); fonctionne parfaitement bien, bien que la création explicite de cette exception particulière soit rare et que la plupart la considéreraient comme un mauvais style.
  • throws déclare qu'une méthode peut lever cette exception. Avec des exceptions non vérifiées, ceci est facultatif, mais peut être utile pour documenter le fait (encore une fois, on ne déclarerait normalement pas throws NullPointerException car c'est à peu près tout à fait donné).
32
Michael Borgwardt

Toutes les exceptions non vérifiées peuvent être traitées de la même manière que celles cochées. Si vous le souhaitez, vous pouvez les laisser passer en déclarant que la méthode throws les:

public void m() throws RuntimeException {}

Ou vous pouvez catch les:

public void m() {
    try {
        // some code
    } catch (RuntimeException re) {
        // do something
    }
}

Il est à noter que la classe RuntimeException agit comme un catch-all pour les exceptions non contrôlées (puisque toutes les exceptions non contrôlées s’étendent de celle-ci), de la même manière que la classe Exception est le catch-all des exceptions vérifiées.

Comme il a été mentionné précédemment, la seule différence réelle est que, pour les exceptions vérifiées, vous devez les manipulez (en les laissant passer ou en les saisissant) et le compilateur s'en charge - par la gestion des exceptions non contrôlées est facultative.

Tout se résume à l'utilisation attendue de chaque type d'exception - vous êtes supposé pouvoir récupérer des exceptions vérifiées (ou au moins faire quelque chose à leur sujet, le cas échéant), tandis que pour les exceptions non vérifiées, il pourrait ne pas y avoir de solution raisonnable. façon de récupérer d'eux. Ceci est bien sûr un peu subjectif.

6
Óscar López

Ils peuvent être manipulés, mais vous n'avez pas à. Si vous ne les gérez pas, elles se propagent et gravissent la pile de méthodes d'appel, jusqu'à ce que l'une d'entre elles l'attrape. Si ce n'est pas le cas, le programme va planter.

Généralement, le résultat final est que si un client peut raisonnablement s'attendre à récupérer d'une exception, il devrait alors s'agir d'une exception cochée. Si un client ne peut rien faire pour récupérer de l'exception, il est correct de l'avoir comme exception non contrôlée.

De même, exceptions vérifiées sont utiles pour documenter une API que vous vous attendez à utiliser. Lorsqu'ils savent que votre méthode peut générer une exception spécifique, ils codent en conséquence et traitent le cas. Si vous utilisez uniquement exceptions non contrôlées, tous les paris sont désactivés.

Un schéma courant (certaines personnes n’aiment pas cela, mais dans certains cas, c’est acceptable quand vous savez ce que vous faites) consiste à intégrer les exceptions vérifiées dans des exceptions non vérifiées.

try {
   ... code that can throw CheckedException ...
} catch (CheckedException oopsSomethingBadHappened) {
    throw new RuntimeException("Something bad happened!", oopsSomethingBadHappened);
}
5
Guillaume

En plus de Guillaume: 

  • les exceptions non contrôlées sont généralement des erreurs de programmation, ce qui ne devrait pas arriver du tout si elles sont correctement implémentées (index hors limite, pointeur null, conversion de classe, ...) et par conséquent l'appelant/utilisateur ne peut généralement rien y faire.
  • les exceptions cochées sont levées car elles échappaient au contrôle du programmeur (réseau non disponible, système de fichiers non disponible, modifications simultanées telles que la clé primaire dupliquée, ...)
  • la JVM génère généralement des erreurs et l’application doit généralement s’arrêter (mémoire insuffisante, débordement de pile, ...)
3
Puce

Un moyen facile de penser à la différence est de penser que la vérification fait référence à la compilation. Si une exception est une exception cochée, le compilateur vérifiera que votre code lève l'exception ou la gère dans un bloc try/catch lors de la compilation. Pour les exceptions non vérifiées, le compilateur ne fera pas une telle vérification. Vous pouvez gérer les exceptions vérifiées/non vérifiées de la même manière (avec try/catch/throws), la différence réside simplement dans les vérifications effectuées par le compilateur. Cet article a un exemple décent. 

3
Chris

Oui, vous pouvez générer des exceptions non vérifiées avec throw. Et oui, vous pouvez intercepter des exceptions non contrôlées dans un bloc catch.

0
tobiasbayer