Je sais que ce serait une mauvaise pratique Bien que je sache que je ne pourrais pas expliquer pourquoi.
int [] intArr = ...
...
try{
int i = 0;
while(true){
System.out.println(intArr[i++]);
}
}catch(ArrayIndexOutOfBoundsException e){}
10 Réponses :
Vous avez raison: des exceptions sont destinées à, ehm, des cas exceptionnels . Les utiliser pour contrôler le flux de contrôle normal ne constituent pas seulement l'intention du code (qui suffirait à disqualifier déjà), mais aussi beaucoup plus lentement, car la lancée et la capture d'exceptions est coûteuse. L'idiome standard (en Java5 et au-dessus) utilise une boucle pourchefer :
+1 C'est pourquoi vous ne devriez pas utiliser INTEGER.PARSE si vous savez que cela échouera régulièrement. Ex analyser les numéros xxxxxx dans lesquels plusieurs personnes ont pu échouer. Au lieu de cela, vous utiliseriez quelque chose comme Int.Tryparse dans C # (équivalent Java). Des exceptions sont rapides quand elles ne sont pas jetées. Mais quand ils sont lancés, ils sont plutôt lents (créez un nouvel objet avec le message, passez à travers beaucoup de captures imbriquées, etc.).
@LASSee pendant que je suis d'accord avec votre logique, je ne crois pas qu'il y ait un équivalent Java de Tryparse
Vous êtes correct. Les exceptions ne doivent pas être utilisées pour gérer le flux de processus.
C'est faux parce que vous savoir que finalement la boucle atteindra le dernier élément de intar , il n'y a donc rien
Manger des exceptions La façon dont vous faites est généralement considérée comme une mauvaise pratique: si vous n'avez pas à faire un traitement supplémentaire, vous pouvez le connecter.
Seulement dans des situations exceptionnelles telles que
Comme toujours "cela dépend" et vous trouverez de nombreuses opinions différentes. Voici le mien
Vous vous attendez à gérer généralement la première catégorie et non celle-ci. Ce dernier est généralement des erreurs de programmation.
Votre exemple tombe dans ce dernier cas, une erreur de programmation. L'exception est destinée à donner de bonnes informations sur l'échec au moment de l'exécution et non comme un flux de contrôle.
Certaines personnes diront que les premières exceptions vérifies et la seconde est décochée. Je serais en désaccord avec ça. Je trouve presque toujours des exceptions vérifiées une douleur en réalité car vous finissez presque toujours à faire / envelopper / réthrow à un autre type d'exception. Lors de la lancée des exceptions et de définir mes propres classes d'exception, j'utilise presque toujours non cochée.
Les exceptions devraient attraper quelque chose d'exceptionnel, en se loger et récupérer si possible.
Si cela fait partie du flux de programme normal, vous devez le gérer normalement.
Les exceptions sont pour exceptions dans le code. Pas pour les cas standard.
Cependant, votre code est plus grave, il est plus lent que ce serait sans utiliser d'exception. Créer l'exception, jeter l'exception et attraper l'exception prend une CPU et une mémoire supplémentaires.
De plus, le code devient plus difficile à lire pour d'autres programmeurs qui n'attendent qu'attendre des exceptions sur des cas d'erreur.
attraper des exceptions n'est qu'une mauvaise pratique quand elle concerne un runtimédiexception . Le arrayindexoutofboundSException que vous essayez d'attraper y a un.
RunTimeExceptions Identifiez si / else , pendant , pour , etc.
Voir aussi:
Atteindre la fin d'un tableau n'est pas un cas exceptionnel. Vous connaissez la longueur avant de commencer à boucler, alors utilisez simplement une idiome standard.
for(int i = 0; i < intArr.length; ++i) {
System.out.println(intArr[i]);
}
Avez-vous lu efficacement Java de Joshua Bloch? Il a un échantillon de code très similaire comme le vôtre et une très bonne explication sur pourquoi ne pas le faire. Je recommande vivement de lire le chapitre d'exception sur ce livre.