Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage Java Java et exceptions

Java et exceptions

9 réponses
Avatar
cho7
Bonjour,

j'ai un cas bizarre d'exception, et je me trouve en train de remettre en
cause mes connaissances en la matière.

De tout temps, j'avais comme idée acquise que si j'ecrivais un truc du genre
"throw new Exception();" au sein d'une fonction, je devais en avertir les
autres via un "throws Exception" dans la déclaration de ma fonction.

Et j'ai constaté que pour le constructeur de java.math.BigDecimal(String),
ce n'est pas le cas ! (Pour Integer(String) pourtant ca y est, alors
pourquoi cette différence, telle est la question...)

Un exemple de ce que l'on peut trouver dans cette classe :

/////////////////////////////////

public BigDecimal(BigInteger unscaledVal, int scale) {
if (scale < 0)
throw new NumberFormatException("Negative scale");

intVal = unscaledVal;
this.scale = scale;
}
////////////////////////////////

J'ai essayé de refaire pareil dans une classe perso, et bien entendu je suis
obligé de mettre un throws, donc c'est quoi le schmilblique ?

Même problème, mais vu sous un autre angle, pourquoi certaines exceptions
n'imposent pas forcément un try-catch ? Je pense encore notamment aux
fonctions lancant NumberFormatException,

si je fais un new Integer("plop"), java ne m'impose pas le try-catch, bien
que je n'ai pas de throws NumberFormatException dans ma fonction courante...

Merci d'éclairer ma lanterne :)

--
cho7
"Plus grosse est la pomme, plus gros est le ver." - cho7, 2005
Signaler un problème avec ce contenu

9 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
seb666fr2
Parce que NumberFormatException est une dérivée de RuntimeException
(erreur à l'exécution) qui est un type d' exception qui ne doit
(théoriquement) pas être catché et qui ne doit (théoriquement) pas
être déclaré dans la clause throws.
Avatar
cho7
a écrit dans le message de news:

Parce que NumberFormatException est une dérivée de RuntimeException
(erreur à l'exécution) qui est un type d' exception qui ne doit
(théoriquement) pas être catché et qui ne doit (théoriquement) pas
être déclaré dans la clause throws.

Ok merci pour l'info.

Sinon pour la théorie c'est bien beau, mais on a interet a catché les
NumberFormatException car ya toujours un neuneu pour mettre des caractères
dans un champs "Age" par exemple...
Avatar
seb666fr2
Dans ce genre de cas, la meilleure solution consiste en l'utilisation
d'un JTextField auquel doit être associé un Document n'acceptant
que les chiffres via un DocumentFilter approprié.
Avatar
cho7
a écrit dans le message de news:

Dans ce genre de cas, la meilleure solution consiste en l'utilisation
d'un JTextField auquel doit être associé un Document n'acceptant
que les chiffres via un DocumentFilter approprié.


Ouép, mais il se trouve que je travaille essentiellement sur J2EE, donc je
continuerai mes try-catch sur les NumberFormatException ;)

Avatar
Thibaut Desmarest
"cho7" a écrit dans le message de
news:43f337ab$0$2375$
a écrit dans le message de news:

Dans ce genre de cas, la meilleure solution consiste en l'utilisation
d'un JTextField auquel doit être associé un Document n'acceptant
que les chiffres via un DocumentFilter approprié.


Ouép, mais il se trouve que je travaille essentiellement sur J2EE, donc je
continuerai mes try-catch sur les NumberFormatException ;)


Si par "je travaille essentiellement sur J2EE" tu veux dire que tes champs
de saisie sont des formulaires HTML, la réponse est la même mais en
remplaçant les DocumentFilter d'un JTextField par des contrôles Javascript
sur tes formulaires. Je suis d'accord avec seb666 pour dire que le contrôle
des données doit se faire en amont lors de la saisie, et non lors du
traitement par ta classe Java. En plus cela permet d'alléger un peu la
charge de ton serveur en laissant tous les tests à la charge du client.
Non ?


Avatar
cho7
Je suis d'accord avec seb666 pour dire que le contrôle
des données doit se faire en amont lors de la saisie, et non lors du
traitement par ta classe Java.


Je m'insurge.

Le controle par javascript n'a qu'un seul avantage : il peut eviter un
aller-retour au serveur tant que la saisie du formulaire n'est pas ok.
En ce sens, il peut effectivement faire économiser de la charge serveur.

Autrement, la règle qui me semble évidente à mes yeux :
NE *JAMAIS* se contenter d'une sécurité coté client.

Il est bien trop facile de contourner une protection javascript, et
d'ailleurs, je connais des personnes qui désactivent purement et
simplement ce même javascript, responsable d'encore bien trop de popups
sur de nombreux sites.

Donc au risque de passer pour un vieux c**, chacunes de mes methodes
setXXXX(String) continuera de lancer une exception si la valeur passée
en paramètre ne concorde pas avec ce qu'on attend d'elle.

Après chacun fait ce qu'il veut hein :)

Avatar
Boogabi
Autrement, la règle qui me semble évidente à mes yeux :
NE *JAMAIS* se contenter d'une sécurité coté client.


Mes profs disent un peu comme toi. Toutes les vérifications possibles
doivent être faites du côté du serveur. Ca n'empêche pas de les faire
également du côté du client, principalement pour faciliter les choses à
l'utilisateur lambda, car il remarquera (au cas où il ne l'avait pas
compris) qu'il ne peut entrer que des chiffres et comprendra donc plus
facilement à quoi correspond ce champ.

Bon, l'exemple ici est un peu neuneu. Mais je peux vous dire que quand
j'ai développé un Rummikub (rien à voir avec le Rubicube), je vérifiais
par exemple du côté serveur que le joueur (client) n'avait pas remplacé
son joker par une plaque qui ne correspond pas. Ca ne m'empêchait pas
d'empêcher au joueur de le faire dans le client (la GUI l'empêchait)
parce que ça aide le joueur à comprendre les règles du jeu.

Alors on peut se demander "Pourquoi vérifier du côté du serveur que le
joueur n'a pas fait un truc qui est de toute façon impossible à faire
?". La réponse est simple... Rien ne me garantit que le client utilisé
est celui que j'ai développé, et que quelqu'un n'a pas développé un
client qui "triche" ou qui oublie certaines vérifications.

Mais si j'ai dit des conneries, n'hésitez pas à me le faire savoir.

Avatar
Alain
Parce que NumberFormatException est une dérivée de RuntimeException
(erreur à l'exécution) qui est un type d' exception qui ne doit
(théoriquement) pas être catché
faux, ca peut et ca doit parfois être catché...

c'est simplement des erreurs jugées très "physiques" et trop fréquente
pour être intéressante à mettre dans Throws ... comme
NullPointerException, MemoryExceprion, SecurityException...

les dérivées d'Exception sont plus "applicatives",
mais entre "checked" et "unchecked" exception (celles que le
compilateur vérifie comme Exception, ou ne vérifie pas comme
RuntimeException) c'est pas un problème simple...

et qui ne doit (théoriquement) pas
être déclaré dans la clause throws.
parfois quand c'est pertinent on les déclare...

ca fait de la doc et c'est très utile ce genre de doc.

typiquement RuntimeException c'est fait pour ce qui indique une erreur
très bas niveau que les couches au dessus n'ont pas de raison de
comprendre...

au mieux il la captent comme une Throwable pour la tracer ou
l'intercepter/retransmettre/encapsuler...
c'est par exemple ce que l'on doit faire quand on a des couches
logicielles bien étanches... on intercepte tout ce qui n'est pas
applicatif (null pointer, memory exception,bad parameters, security
violation) et on génère une erreur applicative "fourre-tout" (genre
ServletException, RemoteException) avec un peu de contexte applicatif
pour la comprendre

Les exception ca devrait être catché une par une avec a la clé quelque
chose de spécifique qui suppose qu'on sais pourquoi l'erreur apparait...

mais parfois des Exceptions arrivent sans qu'on comprenne...
a mon avis on n'a jamais a catcher "Exception" qu'on ne comprend pas,
on catche "Throwable" en désespoir de cause... ce qui catche les
Exception incomprises et les autres RuntimeException pas faite pour être
comprises (par ton code, toi t'as le droit de comprendre, mais ton
programme ne peut pas prendre de décision autre que t'informer ou
ignorer!)...


a noter que si ton code ne comprend pas au moins 75% de code relatifs
aux dysfonctionnements, erreurs et exceptions diverses, c'est que t'as
du oublier quelque chose... l'essentiel du problème est dans les erreurs.





Avatar
seb666fr2
Alain wrote:
Parce que NumberFormatException est une dérivée de RuntimeException
(erreur à l'exécution) qui est un type d' exception qui ne doit
(théoriquement) pas être catché


faux, ca peut et ca doit parfois être catché...


Le rôle des RutimeException est de permettre au programmeur
de repérer les erreurs de programmation. C'est pourquoi il
n'est pas nécéssaire de les déclarer dans la clause throws et
qu'il est préférable de les laisser se propager et de les traiter
en dernier recours (via un UncaughtExceptionHandler par exemple).

c'est simplement des erreurs jugées très "physiques"


c'est à dire ?

et trop fréquente pour être intéressante à mettre dans Throws


non, c'est simplement parce qu'elles permettent de notifier une
erreur de programmation.


les dérivées d'Exception sont plus "applicatives",
mais entre "checked" et "unchecked" exception (celles que le
compilateur vérifie comme Exception, ou ne vérifie pas comme
RuntimeException) c'est pas un problème simple...


Java est d'ailleur un des rare langage à disposer de ces 2 types
d'exceptions. En c++ et en c#, il n'existe que des unchecked-exception.


typiquement RuntimeException c'est fait pour ce qui indique une erreur
très bas niveau que les couches au dessus n'ont pas de raison de
comprendre...

au mieux il la captent comme une Throwable pour la tracer ou
l'intercepter/retransmettre/encapsuler...
c'est par exemple ce que l'on doit faire quand on a des couches
logicielles bien étanches... on intercepte tout ce qui n'est pas
applicatif (null pointer, memory exception,bad parameters, security
violation) et on génère une erreur applicative "fourre-tout" (genre
ServletException, RemoteException) avec un peu de contexte applicatif
pour la comprendre


Je ne suis pas du tout d'accord avec ce point de vue. En procédant de
la sorte, il y a de fait un mélange entre erreur applicative et erreur
de programmation ce qui complexifie le code et sa compréhension
alors qu'il est beaucoup plus simple de laisser les erreurs de
programmation
se propager jusqu'à un point de traitement dédié.

Les exception ca devrait être catché une par une avec a la clé quel que
chose de spécifique qui suppose qu'on sais pourquoi l'erreur apparait...


houla, tu risques d'avoir un code pour le moins incompréhensible la.

mais parfois des Exceptions arrivent sans qu'on comprenne...
a mon avis on n'a jamais a catcher "Exception" qu'on ne comprend pas,
on catche "Throwable" en désespoir de cause... ce qui catche les
Exception incomprises et les autres RuntimeException pas faite pour être
comprises (par ton code, toi t'as le droit de comprendre, mais ton
programme ne peut pas prendre de décision autre que t'informer ou
ignorer!)...



a noter que si ton code ne comprend pas au moins 75% de code relatifs
aux dysfonctionnements, erreurs et exceptions diverses, c'est que t'as
du oublier quelque chose...


Donc 75% de code destiné à la gestion des erreurs et 25% de code
applicatif...cette estimation est pour le moins farfelue.

l'essentiel du problème est dans les erreurs.


pardon ?




--
S.B