Pourquoi “throws Exception” nécessaire lors de l'appel d'une fonction?
class throwseg1
{
void show() throws Exception
{
throw new Exception("my.own.Exception");
}
void show2() throws Exception //Why throws is necessary here ?
{
show();
}
void show3() throws Exception //Why throws is necessary here ?
{
show2();
}
public static void main(String s[]) throws Exception //Why throws is necessary here ?
{
throwseg1 o1 = new throwseg1();
o1.show3();
}
}
Pourquoi le compilateur signale que les méthodes show2()
, show3()
, et main()
ont
non déclarée exception Exception qui doit être pris ou déclarée à être jeté
quand j'enlève throws Exception
de ces méthodes?
- principal peut certainement être déclaré à jeter l'Exception. Si c'est le cas, la JVM va s'arrêter. C'est aussi près de l'ignorant comme le compilateur va permettre.
- Lorsque la méthode appelée (Methdod1) throws
Exception
, nous devons définir la méthode d'appel (Method2) avecthrows Exception
; si nous ne sommes pas remise de cette exception dans la méthode appelante. Le but est de donner des chefs jusqu'à l'appel de la méthode (Method3) de Method2 une Exception peut être levée par Method2 et vous devez gérer ici, sinon il peut interrompre votre programme. - De même, si Method3 n'est pas de la manipulation de l'exception dans son corps puis, il avait pour définir
throws Exception
dans sa définition de la méthode pour donner des chefs sa méthode d'appel. le prolongement de la précédente commentaire
Vous devez vous connecter pour publier un commentaire.
En Java, comme vous le savez peut-être, des exceptions peuvent être classées en deux: l'Un qui a besoin de l'
throws
clause ou doit être traitée si vous ne spécifiez pas l'un et l'autre ne l'est pas. Maintenant, voir la figure suivante:En Java, vous pouvez jeter quoi que ce soit qui s'étend de la
Throwable
classe. Cependant, vous n'avez pas besoin de spécifier unthrows
clause pour toutes les classes. Plus précisément, les classes qui sont soit uneError
ouRuntimeException
ou aucune des sous-classes de ces deux. Dans votre casException
n'est pas une sous-classe d'uneError
ouRuntimeException
. Ainsi, il est vérifié exception et doit être spécifié dans lethrows
clause, si vous n'avez pas à traiter cette exception particulière. C'est pourquoi vous avez besoin d'unethrows
clause.De Java Tutoriel:
Maintenant, comme vous le savez, les exceptions sont classés en deux: activée et désactivée. Pourquoi ces classement?
Vérifié Exception: Ils sont utilisés pour représenter les problèmes qui peuvent être recouvrés au cours de l'exécution du programme. Ils ne sont généralement pas le programmeur de la faute. Par exemple, un fichier spécifié par l'utilisateur n'est pas lisible ou pas de connexion réseau est disponible, etc., Dans tous ces cas, notre programme n'a pas besoin de sortir, au lieu de cela, il peut prendre des mesures, comme d'alerte de l'utilisateur, ou aller dans un mécanisme de secours(comme le travail hors ligne lorsque le réseau n'est pas disponible), etc.
Décoché Exceptions: encore une fois, Ils peuvent être divisés en deux: les Erreurs et les RuntimeExceptions. Une raison pour eux d'être décochée, c'est qu'ils sont nombreux en nombre, et nécessaire pour gérer tous encombrement de notre programme et de réduire sa clarté. L'autre raison est la suivante:
Des Exceptions d'exécution: Elles se produisent généralement en raison d'une faute par le programmeur. Par exemple, si un
ArithmeticException
de la division par zéro se produit ou uneArrayIndexOutOfBoundsException
se produit, c'est parce que nous ne sommes pas assez prudent dans notre codage. Ils se produisent généralement en raison de quelques erreurs dans notre logique de programme. Donc, ils doivent être éliminées avant que notre programme entre dans le mode de production. Ils sont désactivées dans le sens que, notre programme doit échouer lorsqu'il se produit, de sorte que nous les programmeurs peuvent se résoudre à la fois de développement et de test lui-même.Erreurs: Erreurs sont des situations à partir de laquelle habituellement, le programme ne peut pas récupérer. Par exemple, si un
StackOverflowError
se produit, notre programme ne peut pas faire beaucoup de choses, tel que l'augmentation de la taille du programme en fonction de la pile d'appel. Ou si unOutOfMemoryError
se produit, nous ne pouvons pas faire beaucoup pour augmenter la quantité de RAM disponible pour notre programme. Dans de tels cas, il est préférable de quitter le programme. C'est pourquoi ils sont faits décochée.Pour des informations détaillées, voir:
try ... catch
.Java nécessite de les manipuler ou de les déclarer toutes les exceptions. Si vous n'êtes pas de la gestion d'une Exception à l'aide d'un bloc try/catch, alors il doit être déclarée dans la signature de la méthode.
Par exemple:
Devrait être écrit comme:
De cette façon, vous pouvez vous débarrasser de la "jette" l'Exception de la déclaration dans la déclaration de la méthode.
RuntimeException
, qui est.Exception
est vérifié classe d'exception. Par conséquent, tout le code qui appelle une méthode qui déclare qu'ilthrows Exception
doit les gérer ou de les déclarer.La
throws Exception
déclaration est une façon automatique de garder la trace des méthodes qui peut lever une exception prévue mais des raisons inévitables. La déclaration est généralement spécifique sur le type ou les types d'exceptions qui peuvent être levées commethrows IOException
outhrows IOException, MyException
.Nous avons tous ou finira par écrire le code qui s'arrête de façon inattendue et signale une exception en raison de quelque chose que nous n'avions pas prévu avant l'exécution du programme, comme la division par zéro ou de l'indice hors limites. Depuis que les erreurs n'étaient pas attendus par la méthode, ils ne pouvaient pas être "pris" et manipulés avec un try catch clause. Tous les utilisateurs de la méthode serait également connais pas de cette possibilité et de leurs programmes serait également arrêter.
Lorsque le programmeur sait que certains types d'erreurs peuvent se produire, mais souhaitez gérer ces exceptions à l'extérieur de la méthode, la méthode peut "jeter" un ou plusieurs types de dérogations à l'appel de la méthode au lieu de les manipuler. Si le programmeur n'a pas à déclarer que la méthode (peut) lève une exception (ou si Java n'ont pas la capacité de le déclarer), le compilateur ne pouvait pas savoir et il serait pour le futur utilisateur de la méthode de connaître, de les attraper et de les gérer toutes les exceptions de la méthode pourrait lancer. Étant donné que les programmes peuvent avoir de nombreuses couches de méthodes écrites par de nombreux programmes différents, il devient difficile (impossible) de garder une trace de méthodes peut lancer des exceptions.
Même si Java a la possibilité de déclarer des exceptions, vous pouvez toujours écrire une nouvelle méthode non gérée et non déclarées exceptions, et Java compiler et vous pouvez l'exécuter et de l'espoir pour le meilleur. Ce que Java ne vous laisse pas faire est de compiler votre nouvelle méthode, si elle utilise une méthode qui a été déclaré que de lancer une exception(s), à moins que vous poignée de le déclaré exception(s) dans votre méthode, ou déclarer votre méthode que de lancer la même exception(s) ou s'il y a plusieurs exceptions, vous pouvez gérer certains et jeter le reste.
Lorsqu'un programmeur déclare que la méthode renvoie un type spécifique d'exception, c'est juste un moyen automatisé d'avertissement à d'autres programmeurs à l'aide de la méthode qu'une exception est possible. Le programmeur peut alors décider de traiter l'exception ou de la transmettre à l'avertissement en déclarant l'appel de la méthode comme aussi de lancer la même exception. Depuis le compilateur a été averti, l'exception n'est possible dans cette nouvelle méthode, il peut automatiquement vérifier si la future appelants de la nouvelle méthode de la poignée de l'exception ou de la déclarer et de l'application de l'un ou de l'autre pour arriver.
La bonne chose à propos de ce type de solution est que lorsque le compilateur signale
Error: Unhandled exception type java.io.IOException
il donne le nom de fichier et le numéro de ligne de la méthode qui a été déclaré à jeter l'exception. Vous pouvez ensuite choisir de simplement passer la balle et déclarer votre méthode "throws IOException". Cela peut être fait tout le chemin jusqu'à la méthode main où il serait alors provoquer l'arrêt du programme et du rapport de l'exception à l'utilisateur. Cependant, il est préférable de se saisir de l'exception et de les traiter dans une jolie manière d'expliquer à l'utilisateur ce qui s'est passé et comment le résoudre. Quand une méthode ne attraper et manipuler l'exception, il n'a plus à déclarer l'exception. La balle s'arrête là, pour ainsi dire.Seulement de petits changements dans votre programme. Ce qu'Il semble être mal compris par de nombreuses quant à la question principale, est à chaque fois que vous jetez exception vous avez besoin de gérer ça, pas nécessaire dans le même lieu ( ex. 1,2,3 méthode dans votre programme), mais vous devez au premier appel de la méthode à l'intérieur de la 'main'. en un mot, il est "jeter", il faut " attraper/essayez, même si ce n'même méthode lorsqu'une exception se produit.
Comme il est cochée exception dans la méthode show (), qui n'est pas traitée dans cette méthode nous utilisons donc des lancers de mot-clé pour la multiplication de l'Exception.
Puisque vous êtes à l'aide de la méthode show() dans show2() la méthode et vous avez propagé l'exception au moins vous devriez être ici la gestion. Si vous n'êtes pas de la manipulation de l'Exception à la règle , alors vous êtes à l'aide de lance de mot-clé.
C'est donc la raison de l'utilisation jette mot-clé lors de la signature de la méthode.
Si vous propager l'exception, en déclarant les lancers de la directive dans la signature de la méthode actuelle, puis, quelque part le long de la ligne ou de la pile d'appel un try/catch doit être utilisé pour traiter l'exception.
En gros, si vous n'êtes pas de la manipulation de l'exception dans le même endroit que vous le jeter, vous pouvez utiliser "jette" l'exception à la définition de la fonction.