Version imprimable
Bonjour
J'ai le code suivant :
Ici on déclenche toujours une exception, me confirmez vous que le code list.set(key, val); ne sera jamais exécuté ?Code:
2
3
4
5
6
De plus , est ce normat qu'il n'y ai pas de throws sur la méthode ?
Merci d'avance
Bonjour
Je confirme et j'affirme que list.set(key, val) ne sera jamais éxecuté.
C'est normal car UnsupportedOperationException est dérivé de RuntimeException.
list.set(key, val); ne sera jamais executé effectivement.
Il n'y a pas de "throws" car UnsupportedOperationException est ce qu'on appelle une RuntimeException.
L'intérêt du if(true) est du debug, ça te permet d'executer un bout de code en plus ou à la place d'un autre quand tu es en train de développer.
c'est moche, mais je m'en sert pour tromper le compilo.
si tu ne mets pas le if (true), le compilo va refuser de compiler parce que il va te dire que le code apres l'exception ne sera jamais atteint.
le gars ne voulait pas enlever le code apres, : donc if true, et tu embrouilles le compilo ;)
Salut!
En général ce style de programmation est utilisé lors des tests pour contourner certains aspets restrictifs du compilateur.
Par exemple le developpeur voudrais juste tester l'influence de l'exception, s'il avait juste misCode:UnsupportedOperationException();
sans le if(true) le compilateur aurait signaler une erreur concernant la suite de la méthode (list.set(key, val);). Car après un throw (non conditionnelle) on considère que rien n'est plus possible...Code:throw new UnsupportedOperationException("Oops, not fully implemented...");
Oups!
Ma réponse est venue trop tard, désolé!
Donc dans l'état actuel , un appel à cette méthode déclence l'exception de type runtime dans tous les cas ?
Cela veut dire qu'un jour le if et l'exception seront retiré, et le code du dessous utilisé ou modifié ?
C'est pas mieux de mettre un TODO à cet endroit ? ou de faire autrement ?
Salut,
Oui... je m'explique : UnsupportedOperationException est une RuntimeException, et ce type d'exception n'a pas besoin d'être déclarée ni catchée. C'est généralement utilisé pour les exceptions dû à des erreurs de compilation (NullPointeurException, ArrayOutOfBoundException, etc...) afin d'éviter de devoir faire des try/catch à tout bout de champs (toutes méthodes peut renvoyer ce type d'exception).Citation:
Envoyé par elitost
a++
Et il serait bien que plus d'API Java utilisent les RuntimeException au lieu des checked exceptions. Cela rendrait leur utilisation bien souvent plus simple.
uoi mais le code serait moins robuste et les applis planteraient sans savoir pourquoi :!:Citation:
Envoyé par Gfx
Ca dépend comment tu programmes.Citation:
uoi mais le code serait moins robuste et les applis planteraient sans savoir pourquoi
Perso j'ai toujours un catch(Throwable) dans mon UI pour récupérer les erreurs non prévues tels les NullPointer etc... Le code est du coup robuste vu que je ne laisse aucune erreur filtrer sauf si je le souhaite.
D'ailleurs pour parler du problème dont parle Gfx, j'ai ajouté une classe utilitaire dans mes projets pour encapsuler les différentes exceptions dans une seule, ce qui évite d'avoir throws truc, machin, bidule... mais seulement throws monexceptionparente.
c'est un peu le principe de Spring qui passe toutes les exceptions en RunTimeException je crois
Sauf que les RunTimeExceptions ne sont pas prévue pour être "catchés", car ce sont des erreurs de programmation. Donc code plus robuste j'y crois pas. C'est simplement une astuce pour masquer les bug.Citation:
Envoyé par natha
Ou de la fainéantise de traiter toutes les exceptions comme il se doit ? :p
Oui certainement, c'est bien plus simple de capturer une RuntimeException que de chercherpourquoi elle est lancée.Citation:
Envoyé par Satch
Justement, dans ernomement de cas une RuntimeException suffit largement, techniquement et surtout semantiquement.
gronono > Un programme ne sera pas moins robuste avec des RuntimeException. Au contraire, puisque ce sont des exceptions que l'on ne doit pas "catcher", leur apparition en cours d'execution du programme est une excellente indication d'erreur de programmation/configuration.
Les checked exceptions ne devraient etre utilisees que pour des erreurs d'environnement qu'on ne peut pas predire. Le cas des IOException est un excellent exemple : cela peur provenir d'une erreur du disque dur, d'une coupure reseau, etc. Des choses que le programmeur ne peut pas corriger.
Les runtime exceptions, comme il a ete dit, sont la pour notifier les erreurs de programmation que l'on peut corriger. Un excellent exemple est la NumberFormatException.
Les RuntimeException peuvent etre catchees dans les modules de test de l'application et c'est la que l'on doit pouvoir assurer la viabilite du programme. Je considere donc qu'un usage correct des Runtime/Checked exceptions permet au contraire d'avoir un code plus robuste. L'utilisation des seules checked exceptions conduit bien trop souvent au cas du catch vide, du catch/logging ou du catch/message d'erreur. Si la meme checked exception est levee a chaque execution consecutive du programme alors elle devrait etre une runtime exception car c'est une erreur de programmation (on peut bien sur debattre la dessus en prenant l'exemple d'un disque dur completement foutu en l'air qui generera toujours une IOException).
Un tres bon exemple de mauvaise checked exception est la XPathExpressionException levee par l'interpreteur XPath du JDK lorsque la requete XPath est mal formee. Une requete XPath n'est pas quelque chose que l'on doit laisser a l'utilisateur le soin d'entrer. Une levee de cette exception est donc signe d'une erreur de configuration (requete statique) ou de programmation (generation dynamique de la requete qui n'a pas marche). Dans certains cas precis, rien n'empeche *en plus* d'intercepter les RuntimeException si la raison en est documentee (exemple validation d'un champ texte ou l'utilisateur doit saisir une requete XPath - on peut imaginer ce scenario dans un outil de developpement).
Le fait que Java integre les checked exceptions est quelque chose d'excellent mais ce n'est pas une raison d'en abuser. Il ne faut pas suivre aveuglement des preceptes enonces lors de l'apprentissage du langage. Cela me rappelle par exemple l'abus de generation de trio variable privee/getter/setter : on expose sa variable publiquement mais par un moyen detourne qui n'ameliore en rien la securite ou l'architecture de l'API.
Le probleme vient du fait que l'on ne soit pas obligé de catch les Runtimes exception.
On devrait toujours les catch au moins au plus au niveau de l'application.
Prenons par exemple Hibernate qui renvoie des HibernateException (type Runtime).
Si une erreur se produit (par exemple un champ qui n'existe plus) , alors l'application plante au niveau utilisateur => ce qu'il faut eviter.
Cacther les RuntimeException permet de prevoir tous les cas (meme ceux qui ne devraient jamais arriver). On peut alors logger (message technique precis) l'erreur et afficher un message à l'utilisateur (message fonctionnel ou bateau suivant la gestion de l'erreur).
Dans tous les cas, il faudrait toujours traiter les exceptions (les runtimes et les autres).
Sinon je considere que si l'application peut planter alors l'application n'est pas robuste.
Exemple un disque dur en mauvais etat ne devrait pas faire planter l'application, mais generer un message d'erreur à l'utilisateur comme quoi la ressource n'est pas disponible.
Bien sur, chacun fait se qu'il veut.
La gestion des exceptions depend du besoin de l'application et de l'utilisateur final.
A+
Les RuntimeException devraient etre interceptees en phase de test, pas en phase de production. Ce sont des erreurs de programmation qui doivent etre corrigees avant distribution du produit. Les checked exceptions non, car elles dependent de l'environnement.
rhhoo ... et ceux qui debug leurs applications au fur et à mesure avec des affichages en console .... on les appelle comment ? des ancètres ??
Merde .. je savais pas que j'étais si vieux lol
je sais ... ce post n'a pas beaucoup d'intérêt, juste pour dire que les bonnes vieilles méthodes sont parfois (souvent ?) les meilleures ....
Rien de ce qui a ete dit au dessus empeche de debugger en console avec des println(). C'est assez rare que j'ai recours a un debugger personnellement.
On souhaite la bienvenue à Gfx dans le club des papys ^^.
Ouai : pour nous les ancètres sont ceux qui font encore des print(); avec des '\n' à la fin de chaque ligne. (les write, c'est pour les dynosaures :) )
Tout humour mis à part, existe-t-il un moyen efficace de debugguer une application utilisant le multiThreading ?
(ceux qui voudraient dire "ne pas dépasser 2 Thread pour pas t'y perdre, la sortie est par là :twisted: :arrow: )
Utilise un bon debugger et un bon profiler (qui aide a voir la timeline des threads).
oula !! des noms tu as ?
Car utilisateur de la Force je ne suis point.
Juste un petit rappel : avec Java 5.0 il est possible d'ajouter un handler qui traitera toutes les exceptions qui ont remontées tout le stacktrace avec la méthode static Thread.setDefaultUncaughtExceptionHandler() (il est également possible de le redéfinir pour chaque thread)Citation:
Envoyé par gronono
Oui, il faut afficher un message d'erreur aux utilisateurs, mais selon la cible du logiciel un StackTrace peut amplement suffire... Maintenant tu peux très bien utiliser la méthode ci-dessus afin d'éviter de faire des try/catch(Throwable) à tout bout de champs...Citation:
Envoyé par gronono
Ce que veux dire Gfx, c'est une exception ne doit pas obligatoirement être une checked exception, et que les runtime exception ont des avantages non négligeable dans certain cas...
Mais cela n'empêche en rien de les catcher lorsque elles dépendent de données externes au programme...
a++