Throws Exceptions Eclipse
Fermé
otaku-boy
Messages postés
99
Date d'inscription
mardi 2 octobre 2012
Statut
Membre
Dernière intervention
6 janvier 2018
-
9 sept. 2017 à 12:36
KX Messages postés 16753 Date d'inscription samedi 31 mai 2008 Statut Modérateur Dernière intervention 25 novembre 2024 - 10 sept. 2017 à 11:23
KX Messages postés 16753 Date d'inscription samedi 31 mai 2008 Statut Modérateur Dernière intervention 25 novembre 2024 - 10 sept. 2017 à 11:23
A voir également:
- An error has occurred. see error log for more details. org/eclipse/jface/databinding/swt/widgetproperties
- A javascript error occurred in the main process - Forum Matériel & Système
- A java exception has occurred - Forum Minecraft
- Cmos checksum error ✓ - Forum Carte-mère/mémoire
- See tickets avis - Forum Consommation & Internet
- Eclipse download - Télécharger - Langages
1 réponse
KX
Messages postés
16753
Date d'inscription
samedi 31 mai 2008
Statut
Modérateur
Dernière intervention
25 novembre 2024
3 020
9 sept. 2017 à 14:38
9 sept. 2017 à 14:38
Bonjour,
Il n'est pas possible de lister "toutes les exceptions possible et imaginables", si les RuntimeException ne sont pas gérées par le compilateur c'est parce qu'elle ne sont pas liées au code que tu écrits mais à l'état du programme au moment où tu l'exécutes.
Ajouter un throws inutile comme RuntimeException serait contraire aux bonnes pratiques de programmation et les outils d'analyse de qualité de code le sortirait automatiquement en erreur.
Règle Sonar : squid:RedundantThrowsDeclarationCheck
La seule vraie bonne pratique que tu pourrais utiliser c'est de faire des try/catch de RuntimeException aussi souvent que tu en as besoin pour protéger ton interface.
Exemple :
Il n'est pas possible de lister "toutes les exceptions possible et imaginables", si les RuntimeException ne sont pas gérées par le compilateur c'est parce qu'elle ne sont pas liées au code que tu écrits mais à l'état du programme au moment où tu l'exécutes.
Ajouter un throws inutile comme RuntimeException serait contraire aux bonnes pratiques de programmation et les outils d'analyse de qualité de code le sortirait automatiquement en erreur.
Règle Sonar : squid:RedundantThrowsDeclarationCheck
La seule vraie bonne pratique que tu pourrais utiliser c'est de faire des try/catch de RuntimeException aussi souvent que tu en as besoin pour protéger ton interface.
Exemple :
public void foo(String str) throws IOException;
try { foo("bar"); } catch (IOException | RuntimeException e) { // ... }
9 sept. 2017 à 18:42
C'est justement pour que celle-ci remonte jusqu'au "plus haut" niveau du code et qu'on puisse informer l'utilisateur que quelque chose s'est passé. (Car si il y a un problème; c'est de SA faute !)
La règle générale est throws dans le package des données et try/catch(/finally) dans celui des interfaces.
10 sept. 2017 à 02:04
"La règle générale est throws dans le package des données et try/catch(/finally) dans celui des interfaces."
C'est un peu extrême comme vision...
Imaginons que ta base de données crash, ça fera une belle jambe à l'utilisateur d'avoir une SQLException par exemple, en quoi est-ce de sa faute ?
Si tu rentres dans le package de données, les exceptions ne peuvent plus être de la faute de l'utilisateur, car le programme devrait déjà avoir fait des vérifications préalables pour empêcher les données farfelues d'arriver jusque là.
La gestion des exception devrait permettre de remonter une information utile aux couches supérieures. Ce qu'il serait intéressant de faire (pas systématiquement) c'est de faire un try/catch des exceptions, pour les transformer en une nouvelle exception plus explicite en indiquant dans le message d'erreur les détails d'appel de la méthode.
Si je reprends l'exemple de la base de données en panne, il serait intéressant que l'exception finale indique les paramètres de connexion à cette base. Comme ça on n'aura pas à farfouiller le code pour comprendre le problème.
Exemple :
Par contre, jamais cette information ne devrait arriver jusqu'à l'interface client.
Ce que l'on fera c'est une log qui contiendra toute l'information utile à la résolution du problème, mais à l'interface utilisateur on renvoie juste le fait que ça ne marche pas.
10 sept. 2017 à 11:06
"Si tu rentres dans le package de données, les exceptions ne peuvent plus être de la faute de l'utilisateur, car le programme devrait déjà avoir fait des vérifications préalables pour empêcher les données farfelues d'arriver jusque là."
Vérifier les données où et quand elles doivent être traitées avant - justement - qu'elles ne le soient me semble non seulement plus simple mais aussi plus logique. Tant pis si il y a des throws de tout les côtés dans mon code.
10 sept. 2017 à 11:23
Pour autant ce n'est pas comme ça que cela devrait être fait.
Imagine une interface graphique où l'on te demande un login/password, si l'utilisateur oublie de rentrer son mot de passe et envoie le formulaire avec juste le login il faudrait détecter ce problème au plus tôt. Si tu continues les traitements de bout en bout et que tu arrives jusqu'à ta requête SQL avec un mot de passe vide (ou pire : null), l'exception que tu vas récupérer sur ta base de données (une SQLException) n'a plus aucun sens par rapport au problème réel.
Laisser se propager les exceptions jusqu'au plus haut niveau, à la limite pourquoi pas, mais ça ne veut pas dire qu'il faut les lever uniquement au plus bas niveau.
Une exception tu peux très bien la lever dès que tu vois que l'utilisateur n'a pas rempli son mot de passe... Ce qui évite au passage de solliciter la base de données pour rien alors que la requête est forcément vouée à l'échec.