7
votes

Comment attraper une nosuchelementException?

Mon attribution de classe consiste à écrire un programme qui a l'utilisateur saisir un ensemble de valeurs numériques. Si l'utilisateur entre une valeur qui n'est pas un nombre, le programme est censé donner à l'utilisateur 2 secondes de chances d'entrer correctement un numéro et après ces deux chances, arrêtez de demander une entrée et d'imprimer la somme de toutes les valeurs entrées correctement jusqu'à présent. .

tel quel, mon code ne fonctionne pas bien juste. Lorsque le premier numéro non numérique est entré, le programme exécute le code dans le bloc de capture une fois, imprime la ligne "entrée de gimme" au début du bloc d'essai, mais immédiatement exécute le code dans la prise bloquer à nouveau sans attendre que l'utilisateur entrave un autre numéro.

Tout en parcourant mon manuel d'indices, j'ai remarqué cette ligne: "Une nosuchelementException est pas attrapée par aucune des clauses de capture . L'exception reste lancée jusqu'à ce qu'elle soit capturée par un autre bloc d'essai ou la méthode principale se termine. "

ce qui est génial, car maintenant au moins, je sais qu'il y a une bonne raison ça se passe, mais mon manuel n'a pas t contient des informations supplémentaires sur ce quirk, et je n'ai pas été en mesure de trouver des réponses compréhensibles via Stackoverflow ou Google. Donc, ma question est en deux partie:

a) Comment devrais-je me contenter de cela aux fins de cette affectation?

B) Qu'est-ce que cela signifie exactement que l'exception n'est pas capturée par une clause de capture? N'est-ce pas ce que les clauses de capture existent? Je veux une solution à ma mission, mais je veux aussi comprendre pourquoi c'est la façon dont il est, si possible.

merci pour toute aide! < Pré> xxx

java exception-handling

0 commentaires

5 Réponses :

4
votes

Pour l'instant, oubliez de saisir l'exception (ce n'est pas ce que vous voulez faire!). Ce que vous voulez faire, c'est ajouter des appels comme: S.hasdouble () avant d'appeler S.NextDouble ().
La raison pour laquelle vous ne voulez pas attraper cette exception est parce que c'est une exception runtimédie qui est destinée à être utilisée pour être utilisé pour Indiquez une erreur de programmeur, une erreur que vous devriez corriger. P>
Le simple conseil est de ne pas attraper des exceptions que le compilateur ne vous dit pas d'attraper, plutôt que si l'un d'entre eux est levé de la vitesse Besoin de faire à votre code pour que l'exception n'arrive pas. P>
Pour exceptions, le compilateur vous dit que vous devez traiter avec eux, vous faites quelque chose comme: P>
public void foo() throws IOException { // ... code ... }

4 commentaires

Ok, merci, cela a beaucoup de sens. C'était un exercice de programmation à la fin d'un chapitre sur la manipulation des exceptions, donc je suppose que je viens de supposer que j'étais censé attraper au lieu d'éviter d'éviter que cela soit lancé en premier lieu. J'aimerais que mon manuel avait précisé que les exceptions d'exécution ne soient pas censées être attrapées, cela semble être un concept assez important pour ne pas orthographier pour un débutant. Merci encore!!!

Réponse courte ... Livres sucer :-) Réponse longue ... Il y a beaucoup de choses à couvrir et à lancer beaucoup de choses chez les étudiants à la fois, ce n'est pas un bon moyen de le faire.

@Erika E - La vraie raison que votre manuel ne donne pas ce conseil est ... imo ... que c'est un conseil incorrect! Voir ma réponse pour une explication.

Un étudiant qui vient d'apprendre n'a pas le besoin de juger quand il est «d'accord» d'attraper une exception d'exécution. L'orthographe de toutes les "règles" n'est pas viable car elles seront touchées avec trop à mémoriser. Les règles plus simples sont mieux à l'avance. Comme la personne gagne plus d'expérience, il est temps de les présenter progressivement aux «exceptions» aux «règles». Mes étudiants sont essentiellement informés de ne pas suivre mes tests de l'unité (qui prennent des captures) lorsque vous envisagez les solutions fournies. Avec le temps, ils apprennent de plus en plus sur ce qu'il faut faire dans certains cas.

1
votes

Vous vous trompez: scanner.nextdouble jette un nosuchelementException si l'entrée est épuisée, ce qui est peu susceptible de se produire avec une entrée standard (elle bloquera à la place). Une valeur incorrecte produira une INPUTMISMATEXCEPTION .
Mon devinez, cependant, est que NextDouble ne supprime pas la valeur incriminée du flux de défaillance. Vous aurez besoin de "effacer" l'entrée dans votre capture avant de reprendre la lecture.
1 commentaires Merci, c'était aussi extrêmement utile! Je n'ai pas pensé à ne pas supprimer la valeur. J'ai ajouté "trash de chaîne = in.Suivant ();" à ma nouvelle clause d'autre (au lieu de capture).
1 votes @ToFubear States: Le simple conseil est de ne pas attraper des exceptions que le compilateur ne vous dit pas d'attraper, si l'un d'entre eux est levé de savoir le changement que vous devez apporter à votre code afin que l'exception ne se produise pas. < / p> Je pense que c'est une simplification excessive. Il est vrai que des exceptions déclarées comme des exceptions vérifiées doivent être axées ou déclarées telles que jetées dans la signature de méthode. Il est également vrai que vous n'avez pas à attraper des exceptions non vérifiées et que vous devriez bien penser que cela soit sage d'attraper une notification. (Par exemple, vous devriez penser si l'exception est lancée au point que vous attendez et pour les raisons que vous attendez.) Cependant, dans certaines circonstances, il est clairement nécessaire de les attraper. Par exemple: xxx Si vous n'avez pas attrapé NumberFormatxception ... qui est un non coché exception ... Ensuite, vous ne seriez pas en mesure d'imprimer un message amical et de demander à l'utilisateur d'essayer à nouveau. En bref, des exceptions non cochées ne signifient pas toujours l'erreur de programmation. Quelques-uns des standard Pourraient indiquer une mauvaise entrée d'un utilisateur ou d'un client (par exemple, NumberFormatException, IllegalargumentException, Arithméticepxception, etc.), ouc. EM> pourraient indiquer quelque chose qu'une application spécifique peut récupérer de, ou du moins tenter de diagnostiquer. J'ai rencontré des bibliothèques tiers dans lesquelles le concepteur a une aversion pour vérifier des exceptions et a déclaré toutes les exceptions de la bibliothèque comme non cochées. (Mauvais design imo, mais cela arrive ...) Donc, une déclaration de couverture que vous ne devriez pas attraper des exceptions non cochées est clairement erronée des conseils erronés. Cependant, la deuxième partie des conseils de @ ToFubear est valide. C'est (généralement) une meilleure idée de faire un test pour empêcher une exception anticipée de se produire que de faire l'action et de saisir l'exception. (Le code est généralement plus simple et généralement plus efficace ... bien qu'il y ait des exemples de compteur.) Dans ce cas, si vous appelez et testez hasnextDouble () avant avant NextDouble () Vous pouvez éviter le boîtier d'erreur que vous essayez de gérer avec l'essai / prise. 8 commentaires "Je pense que c'est une simplification excessive." J'essayais de garder cela simple pour quelqu'un qui ne sait pas sur des exceptions. Votre exemple de NumberFormatException est un mauvais exemple. La fonction Paysint est cassée - il devrait lancer une exception vérifiée, ou une autre méthode doit y avoir une autre méthode (chaîne) que vous pouvez appeler pour éviter l'exception. J'utilise personnellement une regex pour vérifier que quelque chose est un INT avant d'appeler Paysint. Je changerai ma déclaration de couverture en vous devriez seulement jeter des exceptions non cochées pour indiquer une erreur de programmeur (qui, de la malédiction, me permet de garder mon autre déclaration de couverture :-) Hé - il n'est pas pertinent que l'analyse est "cassée". Le fait est que c'est un cas commun où vous avez besoin d'attraper une exception décochée. Et comme tel c'est un bon exemple. "J'essayais de garder cela simple pour quelqu'un qui ne sait pas des exceptions." C'est une mauvaise idée de simplifier votre message dans la mesure où vous finissez par donner le mauvais message. Et ce cas, j'ai pensé qu'il était suffisamment faux que j'ai passé une page de texte à rebuttal. Non, ce n'est pas un bon exemple ... Utilisez une regex avant d'analyser, puis n'appelez pas parseint s'il va lancer. Prenez un coup sur celui-ci s'il vous plaît ... Stackoverflow.com / Questions / 613954 / ... @Tofubeer - vous manquez mon point. C'est un bon exemple de pourquoi il peut être nécessaire d'attraper des exceptions non cochées . Et en plus, en utilisant integer.parseint (sans la première vérification avec une regex) n'est pas erroné ... Outre l'argument circulaire qu'il est faux parce qu'il jette une exception non cochée . Quoi qu'il en soit, vous ne vous persuaderez pas que c'est un mauvais exemple ... alors laisse tomber cela. @Tofubeer - J'ai examiné cette question. Je n'ai rien de substantiel à ajouter que cela n'a pas été dit. La seule chose que j'aurais pu ajouter est qu'il existe une réelle différence entre la manière dont les exceptions non cochées doivent être utilisées et la manière dont ils sont utilisés utilisés. Je vais le laisser tomber ... mais mon dernier mot est simplement, il n'est pas nécessaire d'attraper une exception d'exécution dans ce cas car il existe une solution parfaitement bonne pour que l'exception ne se produise jamais. 0 votes entourez vos déclarations autour de TRY..Catch est une bonne idée lorsque vous n'avez aucune idée que ce qui se passera dans le scénario réel. Mais j'ai une solution alternative, la plupart du temps, nous connaissons cette augmentation d'exception afin que vous puissiez l'éviter à l'aide de la mise en œuvre d'itérateur comme suit. XXX 0 commentaires -2 votes Vous devez modifier l'importation. au lieu de xxx Utilisez xxx 0 commentaires

Articles qui pourrait vous intéresser : Comment envoyer une liste vide à la clause IN Code de réponse 403 inattendu lors de la récupération des données des API Impossible de trouver la classe UnityPlayerActivity dans com.unity3d.player Comment définir un tableau dans jsonobject