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

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:

---

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

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

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.

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 ?

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 :yaisse2:

Citation:

---

Envoyé par herve91

Il suffirait en effet :yaisse2:

---

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.

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

Quel est le projet que tu as vu?

Comment faisait-il?

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.

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.

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.

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.

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 :aie:

a++

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

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 :aie:

F.

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.

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 ! :mrgreen:

Citation:

---

Envoyé par natha

Ouahhh c'est la classe ton écran ! :) J'aimerais bien avoir autant ! :mrgreen:

---

C'est pas le mien malheureusement :( J'en suis encore à 1280*1024, mais par contre, j'en ai 2 8-)

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 ? :aie:

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.

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 ? :aie:

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 :roll:

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.

On peut discuter des calculs avec virgules alors aussi...
0.1 + 0.2 par exemple qui a une chance sur 3 de te donner autre chose que 0.3 ! Et je trouve super-pénible de devoir passer par des BigDecimal initialisés avec des objets de type String pour avoir un calcul correct.

C'est clair que sur les calculs en float, y a de quoi dire...
Dans tous les cas, personnellement, je trouve dommage que l'overflow ne provoque pas d'erreur. Comme dit dans l'un des post, pour retrouver l'erreur, bonjour le travail !
Et je ne pense pas qu'on puisse prévoir à l'avance tout ce qu'un utilisateur pourra saisir... Pire, il se trompe, mais ça passe quand même (en faussant les données au passage)

A+

Citation:

---

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

---

ET LES MATHS là, 2560*1600 = environ 4 millions.
Un int peut contenir 2 puissance 32 soit environ 4300 millions.
Un long peut contenir 2 puissance 64 soit environ 18 millions de millions de millions.
Desoler mais ce n'est pas un ecran qui fera sortir des limites, à moins que celui ci ne recouvre Saturne, et encore.
Bien sur il ne faut pas prendre un byte ou un short pour faire les calculs :)
Et toc :)

Citation:

---

Envoyé par openWorld

ET LES MATHS là, 2560*1600 = environ 4 millions.
Un int peut contenir 2 puissance 32 soit environ 4300 millions.
Un long peut contenir 2 puissance 64 soit environ 18 millions de millions de millions.
Desoler mais ce n'est pas un ecran qui fera sortir des limites, à moins que celui ci ne recouvre Saturne, et encore.
Bien sur il ne faut pas prendre un byte ou un short pour faire les calculs :)
Et toc :)

---

Faux.

La valeur max de int, c'est 2 puissance 31 moins 1, soit 2'147'483'647.

La preuve avec la javadoc :

Citation:

---

MAX_VALUE
A constant holding the maximum value an int can have, 2pow31-1

---

Citation:

---

Envoyé par Baptiste Wicht

Faux.

La valeur max de int, c'est 2 puissance 31 moins 1, soit 2'147'483'647.

La preuve avec la javadoc :

---

On est quand meme loin d'arriver à un overflow avec ton exemple :roll:

Citation:

---

Envoyé par Baptiste Wicht

Faux.

La valeur max de int, c'est 2 puissance 31 moins 1, soit 2'147'483'647.

La preuve avec la javadoc :

---

Et oui, il faudrait avoir un unsigned int pour arriver aux 4 millions et plus...

Pour les histoires de performances, ce serait au moins sympathiques qu'il existe une option de la JVM pour lancer des exceptions d'overflow en cas d'overflow...

Si le bug est reproductible, il serait alors possible d'activer cette option pour repérer plus rapidement l'erreur (quitte à avoir une application 10 fois plus lente en environnement de test pour débugger ce type de problème).

Citation:

---

Envoyé par millie

Pour les histoires de performances, ce serait au moins sympathiques qu'il existe une option de la JVM pour lancer des exceptions d'overflow en cas d'overflow...

---

Je trouve qu'il serait plus intéressant qu'un overflow soit systématiquement une erreur, le cas inverse me semble plus anecdotique...
Dans tous les cas, l'option de la jvm ne me semble pas bonne, il faudrait déjà savoir qu'on est en présence d'un problème lié à l'overflow pour le corriger.

Quel sont les cas où l'overflow serait utilile ? Moi, j'en vois pas ;)

Citation:

---

Envoyé par OButterlin

Dans tous les cas, l'option de la jvm ne me semble pas bonne, il faudrait déjà savoir qu'on est en présence d'un problème lié à l'overflow pour le corriger.

---

Il suffirait en cas de problème non habituel de lancer la JVM en mode test qui regrouperait un ensemble d'option du type "tester les overflow".

Evidemment, il est plus intéressant qu'un overflow soit tout le temps détecté, mais as tu une idée de la dégradation des performances que cela engendre ? (moi non, mais si tu me dis que ça change rien alors c'est sûr que c'est mieux que ce soit tout le temps présent :mouarf:)

Citation:

---

Envoyé par millie

Evidemment, il est plus intéressant qu'un overflow soit tout le temps détecté, mais as tu une idée de la dégradation des performances que cela engendre ? (moi non, mais si tu me dis que ça change rien alors c'est sûr que c'est mieux que ce soit tout le temps présent :mouarf:)

---

ben pour être franc, j'en sais rien du tout... j'imagine que ça ne devrait pas être la lune, mais d'un autre côté, s'ils ne l'ont pas fait, il est possible que si :aie:

Baptiste Wicht oui je parlais en unsigned. Tu m'en voudras pas si ya une d'un coefficent 2. T'a fait une erreur d'un coefficient 8000 ::) hihihi
Menfin aucune importance

Et si on allait voir ce que font les concurrents? :mrgreen:

En C# en l'occurrence, les overflows sont très bien gérés. Une exception est lancée en cas de dépassement de capacité lors d'une opération arithmétique ou d'un cast.

Il est ainsi possible d'activer ou de désactiver la vérification du dépassement de capacité d'une opération arithmétique particulière ou d'un cast via les 2 mot clés spécifiques checked et unchecked.

Petit exemple d'utilisation (tiré de la msdn):

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

//code c# short x = 32767; // Max short value short y = 32767; int z = 0; try { z = checked((short)(x + y)); Console.WriteLine(z); } catch (System.OverflowException e) { Console.WriteLine(e.ToString()); //dépassement de capacité, on entre dans le catch, z ne sera jamais affiché }

---

Enfin, il existe une option particulière du compilateur c# (csc de son petit nom) qui permet également d'activer ou non la vérification du dépassement de capacité pour toutes les opération arithmétique pour lequelle il n'a pas été spécifié de mot clé checked ou unchecked, c'est l'option /checked.

Ca doit bien être faisable en Java, non?


Edit : j'ai oublié de préciser, par défaut (pas de mot clé checked ou unchecked mis devant une opération, option checked du compilo non utilisée), C# ne contrôle pas les dépassement de capacité (mode unchecked donc).

Je ne connais pas la norme IEEE 754. Je vais quand même essayer de faire avancer le débat.

Within an FP-strict expression, all intermediate values must be elements of the float value set or the double value set, implying that the results of all FP-strict expressions must be those predicted by IEEE 754 arithmetic on operands represented using single and double formats. Within an expression that is not FP-strict, some leeway is granted for an implementation to use an extended exponent range to represent intermediate results; the net effect, roughly speaking, is that a calculation might produce “the correct answer” in situations where exclusive use of the float value set or double value set might result in overflow or underflow.

JLS3 §15.4

Citation:

---

Quel sont les cas où l'overflow serait utilile ? Moi, j'en vois pas

---

Ca m'a déjà été utile quelques fois, même si c'est vrai que ça ne sert pas tous les jours et à tout le monde. On peut l'utiliser par exemple faire un checksum basique:

Code:

---

1 2	int checksum=0; for(int i=0; i<byteArrayToCheck.length; i++) checksum += byteArrayToCheck[i];

---

Ceci dit, un comportement comme celui du C# serait préférable:
- Une option à la ligne de commande pour activer/désactiver la vérification(désactivé par défaut pour la compatibilité, même si je trouverai plus sur que ce soit activé par défaut),
- Tout en conservant la possibilité de spécifier individuellement le comportement des variables dont on attend un comportement particulier, comme la variable checksum de mon exemple.