Discussion :

[elitost]

Bonjour

J'ai le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
   public void setValue(String key, Object value) {
      if (true) {
         throw new UnsupportedOperationException("Oops, not fully implemented...");
      }
      list.set(key, val);
   }

Ici on déclenche toujours une exception, me confirmez vous que le code list.set(key, val); ne sera jamais exécuté ?

De plus , est ce normat qu'il n'y ai pas de throws sur la méthode ?

Merci d'avance

[jowo]

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.

[natha]

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.

[lunatix]

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

[professeur]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

UnsupportedOperationException();

, s'il avait juste mis

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

throw new UnsupportedOperationException("Oops, not fully implemented...");

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...

[professeur]

Oups!

Ma réponse est venue trop tard, désolé!

[elitost]

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 ?

[adiGuba]

Salut,

De plus , est ce normat qu'il n'y ai pas de throws sur la méthode ?

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).

a++

[Gfx]

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.

[gronono]

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

[natha]

uoi mais le code serait moins robuste et les applis planteraient sans savoir pourquoi

Ca dépend comment tu programmes.
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.

[lunatix]

c'est un peu le principe de Spring qui passe toutes les exceptions en RunTimeException je crois

[Deadpool]

uoi mais le code serait moins robuste et les applis planteraient sans savoir pourquoi

Ca dépend comment tu programmes.
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.

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.

[Satch]

Ou de la fainéantise de traiter toutes les exceptions comme il se doit ? :p

[Deadpool]

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.

[Gfx]

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.

[gronono]

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+

[Gfx]

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.

[NeptuS]

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 ....

[Gfx]

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.