Overflows numériques, pourquoi Java ne les gère pas ?

Baptiste Wicht · 07/12/2007, 12h16

Bonjour,

Je me demandais s'il y avait une raison au fait que Java ne gère pas les overflows des types numériques ?

Parce qu'en fait, je pense que c'est très largement possible de le faire dans le langage et ce serait tout de même plus confortable pour l'utilisateur et évidemment une source d'erreur en moins...

Je dis ça, parce que j'ai vu une présentation d'un programme permettant de détecter les overflow de types numériques dans un programme quelconque et j'ai trouvé étonnant que Java ne le fasse pas lui-même...

Qu'en dites-vous ?

Pensez-vous que ce soit juste pas simplicité ou est-ce qu'il y a une meilleure raison ? Et pensez-vous que ce soit une bonne idée de ne pas gérer ces overflows ou non ?

======

Pour ceux qui ne savent pas de quoi, je parle, essayez le code suivant :

Code :

int i = 100000 * 500000;
System.out.println(i);

Logiquement, ce calcul devrait donner 50000000000, mais ce nombre est plus grand que la valeur maximale de int (2147483647) et Java vous donne ce résultat :

Citation:

-1539607552

Bluffant, non ?

En fait, c'est tout simplement parce que le int étant codé sur du 32 bits, Java calcule le résultat et ne prend que les 32 derniers bits du résultat et les redonne.

Ce qui nous donne un nombre négatif...

Pour ceux qui ont de la peine avec le binaire, vous pouvez vous représenter ça comme un cercle dans lequel on tourne infinement, quand on atteint la limite maximale du nombre, on continuer à tourner mais le prochain nombre est le plus petit du type.

Donc si vous prenez la valeur maximale de int et vous lui rajoutez un, vous arrivez à la valeur minimale de int (-2147483648).

openWorld · 07/12/2007, 13h15

Je ne vois pas comment il pourair gerer le overflow.
Lancer une exception a chaque operation numerique. Pas super pour la lisibilite du code.

herve91 · 07/12/2007, 13h31

Effectivement, la spec est claire sur ce point :

Citation:

The built-in integer operators do not indicate (positive or negative) overflow in any way; they wrap around on overflow. The only integer operators that can throw an exception are the integer divide and integer remainder operators, which can throw an ArithmeticException if the right-hand operand is zero.

Je pense que c'est avant tout pour des soucis de performance.
Maintenant, si nécessaire, il est possible de gérer à la main la gestion de l'overflow, si celle-ci a une forte chance de se produire. En clair, il faut maitriser les calculs que l'on fait

éventuellement faire des assertions sur les valeurs d'entrée avant le calcul pour être sûr que ces dernières sont bien à l'intérieur des plages requises pour le calcul.

Citation:

Je ne vois pas comment il pourair gerer le overflow.

A l'aide d'un indicateur de débordement ? c'est classiquement le cas lors d'opérations arithmétiques sur des processeurs physiques.

Baptiste Wicht · 07/12/2007, 13h31

Citation:

Envoyé par openWorld

Je ne vois pas comment il pourair gerer le overflow.
Lancer une exception a chaque operation numerique. Pas super pour la lisibilite du code.

Il suffit de lancer des exceptions non controlées de la même manière que c'est fait avec NullPointerException non ?

herve91 · 07/12/2007, 13h33

Citation:

Envoyé par Baptiste Wicht

Il suffit de lancer des exceptions non controlées de la même manière que c'est fait avec NullPointerException non ?

Il suffirait en effet

Baptiste Wicht · 07/12/2007, 13h39

Citation:

Envoyé par herve91

Il suffirait en effet

Bon, c'est clair que c'est plus facile à dire qu'à faire.

C'est vrai que s'il fallait contrôler chaque opération mathématique, ça pourrait pourrir les performances...

Mais dans le projet que j'avais vu, ça ne cassait pas trop les performances du programme.

sinok · 08/12/2007, 03h39

Enfin si tu touches à des nombres aussi grands mieux vaudrait employer BigInteger

LGnord · 08/12/2007, 09h04

Quel est le projet que tu as vu?

Comment faisait-il?

Baptiste Wicht · 08/12/2007, 09h35

Citation:

Envoyé par LGnord

Quel est le projet que tu as vu?

Comment faisait-il?

C'était le projet de Bachelor de deux étudiants.

En fait, ils modifiaient le bytecode de l'application à tester pour rajouter des instructions de tests et envoyer chaque overflow vers un fichier ou une base de données.

Par contre, ça augmentait pas mal la taille du .jar alors ils avait une deuxième méthode avec l'inlining pour que la taille soit plus petite, mais les performances étaient bien moindres.

Mais les perfs et la taille n'ont que peu d'importance, l'application étant surtout destinée à tourner durant le développement et pas en production.

mavina · 08/12/2007, 14h30

Le problème est que si tu fais une exception du genre NullPointerException (donc une RuntimeException qui arrette ton programme), dès que tu as un overflow quelconque (ca arrive vite avec des multiplications d'entier) sur un nombre, c'est la misère à gérer, tu ne pense pas ?
Imagine une calculatrice, il faudrait tout faire avec des BigInteger tout simplement parceque tu ne peux pas prévoire ce que l'utilisateur va rentrer et que tu risques d'avoir une exception si une multiplication trop grande est rentrée...

Donc on en arriverai à l'inutilité du primitif int et BigInteger lui sera préféré dans un grand nombre de cas, ce qui ne simplifierai pas la lisibilité des codes.

F.

Baptiste Wicht · 08/12/2007, 14h48

Citation:

Envoyé par mavina

Le problème est que si tu fais une exception du genre NullPointerException (donc une RuntimeException qui arrette ton programme), dès que tu as un overflow quelconque (ca arrive vite avec des multiplications d'entier) sur un nombre, c'est la misère à gérer, tu ne pense pas ?
Imagine une calculatrice, il faudrait tout faire avec des BigInteger tout simplement parceque tu ne peux pas prévoire ce que l'utilisateur va rentrer et que tu risques d'avoir une exception si une multiplication trop grande est rentrée...

Donc on en arriverai à l'inutilité du primitif int et BigInteger lui sera préféré dans un grand nombre de cas, ce qui ne simplifierai pas la lisibilité des codes.

F.

Personnellement, je préfère avoir une calculatrice qui plante plutôt qu'une calculatrice qui m'affiche une valeur fausse...

Pour une calculatrice, c'est différent, ils n'ont pas le droit à l'erreur. En plus,tu peux tout à fait limiter ce que l'utilisateur va entrer.

De plus, tu compares avec une NullPointerException, mais est-ce qu'on les catche ? Non

Je pense qu'on ne devrait pas avoir d'overflow dans un programme, c'est une source d'erreur difficile à tracer. Donc, oui, je préférerais que mon programme plante à chaque overflow comme il plante à chaque pointeur null sur lequel on invoque une méthode.

mavina · 08/12/2007, 14h56

C'est un choix de conception qu'a fait Sun vis à vis des overflows.
Si tu dois catcher une exception à chaque opération sur un int, t'as pas fini...

Citation:

plus, tu compares avec une NullPointerException, mais est-ce qu'on les catche ? Non

A la base c'est toi qui as cité le NullPointerException :

Citation:

Il suffit de lancer des exceptions non controlées de la même manière que c'est fait avec NullPointerException non ?

Non on ne les catch pas, c'est une RuntimeException, ce qui veut dire que lorsqu'elle est déclanchée, java considère que ton programme ne peut continuer à tourner normalement, et il s'arrette.
Si tu fais pareil avec un overflow numérique, on est vite embetté.
Je ne dis pas que c'est une bonne solution qu'ils ont choisie, mais serait-il vraiment mieux d'arretter le programme pour un overflow numérque ?

Je n'en suis pas si sûr...

F.

adiGuba · 12/12/2007, 17h23

Salut,

Citation:

Envoyé par mavina

Si tu dois catcher une exception à chaque opération sur un int, t'as pas fini...

Justement non : en utilisant des RuntimeException on n'est pas obligé de les catcher. D'ailleurs tu ne traites pas les ArithmeticExceptions qui peuvent pourtant être propagés...

Il y aurait un grand intérêt à cela, c'est d'avoir un code "fail-fast", c'est à dire qui plante rapidement.

Dans la plupart des cas, lorsqu'un overflow numérique survient, cela entraine de gros dysfonctionnement de l'application, dont il n'est pas forcément évident de trouver la source (puisque le calcul erroné a pu être effectué bien avant le moment où cela posera problème).

En remontant une exception dès l'overflow on obtient rapidement la cause exacte de l'erreur !

Comme tu le dis en cas d'overflow il vaut mieux arrêter le programme, donc une exception serait la bienvenue...

Maintenant j'ignore la raison exacte qui fait qu'il n'y a pas d'exception sur les overflow numérique... peut être que cela se révèle trop couteux en terme de performance...

Une JVM de test qui ferait cela pourrait en effet être utile pour le développement et les tests... quoique dans la pratique les overflow se produise surtout en prod

a++

openWorld · 12/12/2007, 22h44

faut deja faire une application balaise qui depasse la valeur d'un long

Autant dire qu'il y a uniquement à l'ESA(et autres variantes nationales) qu'ils ont besoin verifier les owerflow. ET Encore.
Je me trompe?
2^64 imaginez un peu ya de quoi compter tout les micrometre d'ici aud ela de la grande ourse

mavina · 13/12/2007, 00h27

Citation:

Envoyé par adiGuba

...

Je suis en partie d'accord avec toi, mais dépasser une capacité et faire une division par zéro sont deux choses différentes.

Diviser par zéro est une chose impossible, aller au delà de 2^32 l'est. Donc aller au dela de 2^32 n'est pas exceptionnel, donc il n'y a pas lieu d'avoir une exception.

Je comprend que le fait d'avoir un code fail fast soit interessant, mais on va vite vers de l'assistanat (et java a déjà une mauvaise réputation à ce propos

). Si tu sais que tu risques un dépassement de capacité en int, tu pars sur du long ou sur du big integer plutot que de partir sur du int.

Comme tu le dis, qui dit vérification dit perte de performances. M'est avis qu'ils ont du tester et vite abandonner l'idée, ca a du plomber les bench

F.

Baptiste Wicht · 13/12/2007, 06h37

Citation:

Envoyé par openWorld

faut deja faire une application balaise qui depasse la valeur d'un long

Autant dire qu'il y a uniquement à l'ESA(et autres variantes nationales) qu'ils ont besoin verifier les owerflow. ET Encore.
Je me trompe?
2^64 imaginez un peu ya de quoi compter tout les micrometre d'ici aud ela de la grande ourse

Un long peut-être, mais un int (2 147 483 648), c'est pas si grand que ça...

Tu prends déja le nombre de pixels d'un écran en 2560*1600 et tu arrives à plus de deux fois ce résultat.

natha · 13/12/2007, 08h04

Citation:

Envoyé par Baptiste Wicht

Tu prends déja le nombre de pixels d'un écran en 2560*1600 et tu arrives à plus de deux fois ce résultat.

Ouahhh c'est la classe ton écran !

J'aimerais bien avoir autant !

Baptiste Wicht · 13/12/2007, 08h12

Citation:

Envoyé par natha

Ouahhh c'est la classe ton écran !

J'aimerais bien avoir autant !

C'est pas le mien malheureusement

J'en suis encore à 1280*1024, mais par contre, j'en ai 2

mavina · 13/12/2007, 08h36

Citation:

Envoyé par Baptiste Wicht

Tu prends déja le nombre de pixels d'un écran en 2560*1600 et tu arrives à plus de deux fois ce résultat.

Alors dans ces cas là tu réfléchis et tu codes avec des long et pas avec des int nan ?

Enfin je dis ça moi je dis rien, tu cherche un peu à nous montrer que java ne te signale pas des erreurs que visiblement tu peux prévoire et dont tu peux te passer facilement

F.

Baptiste Wicht · 13/12/2007, 08h50

Citation:

Envoyé par mavina

Alors dans ces cas là tu réfléchis et tu codes avec des long et pas avec des int nan ?

Enfin je dis ça moi je dis rien, tu cherche un peu à nous montrer que java ne te signale pas des erreurs que visiblement tu peux prévoire et dont tu peux te passer facilement

F.

Bien sûr que ce cas-là, tu peux prévoir

Je cherche juste à montrer que c'est très vite fait avec une multiplication de sortir des limites...

N'empêche que même pour le coup de l'écran, le débutant qui calcule ça, je suis sûr qu'il ne comprendra pas pourquoi ça lui donne des nombres impossibles quand il passe sur des gros écrans.

08/12/2007, 03h39	#7
sinok Modérateur Inscription: août 2004 Localisation: Paris Âge: 30 Messages: 6 720	Enfin si tu touches à des nombres aussi grands mieux vaudrait employer BigInteger __________________ Alors, j'suis pourrave ou j'suis pourrave? Mais ce n'est pas pour autant que j'accepte les questions techniques par MP... Pareil pour MSN
	00

08/12/2007, 14h30	#10
mavina Responsable IRC Nom : Frédéric Mora Inscription: octobre 2004 Localisation: Tokyo Âge: 25 Messages: 1 835	Le problème est que si tu fais une exception du genre NullPointerException (donc une RuntimeException qui arrette ton programme), dès que tu as un overflow quelconque (ca arrive vite avec des multiplications d'entier) sur un nombre, c'est la misère à gérer, tu ne pense pas ? Imagine une calculatrice, il faudrait tout faire avec des BigInteger tout simplement parceque tu ne peux pas prévoire ce que l'utilisateur va rentrer et que tu risques d'avoir une exception si une multiplication trop grande est rentrée... Donc on en arriverai à l'inutilité du primitif int et BigInteger lui sera préféré dans un grand nombre de cas, ce qui ne simplifierai pas la lisibilité des codes. F. __________________ Consultant IT au Japon Mon blog et mes publications Mon dernier tutoriel : Messages Quit IRC : explications La rubrique IRC recrute des redacteurs : contactez moi Ce flim n'est pas un flim sur le cyclimse. Merci de votre compréhension.
	00

07/12/2007, 13h15	#2
openWorld Membre régulier Inscription: mai 2007 Messages: 117	Je ne vois pas comment il pourair gerer le overflow. Lancer une exception a chaque operation numerique. Pas super pour la lisibilite du code.
	00

08/12/2007, 09h04	#8
LGnord Membre du Club Inscription: février 2007 Messages: 93	Quel est le projet que tu as vu? Comment faisait-il?
	00

12/12/2007, 22h44	#14
openWorld Membre régulier Inscription: mai 2007 Messages: 117	faut deja faire une application balaise qui depasse la valeur d'un long Autant dire qu'il y a uniquement à l'ESA(et autres variantes nationales) qu'ils ont besoin verifier les owerflow. ET Encore. Je me trompe? 2^64 imaginez un peu ya de quoi compter tout les micrometre d'ici aud ela de la grande ourse
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email