Decimal : La validation d’un formulaire génère une erreur en preRelease et pas d’erreur en Release

Decimal : La validation d’un formulaire génère une erreur en preRelease et pas d’erreur en Release
0
Tags: #<Tag:0x00007f8535c8b920>

Bonjour,

Quand je valide le formulaire de l’objet « ImmoFinancialElement » en preRelease, j’obtiens les erreurs suivantes :

2019-09-30 09:54:30,248 ERROR [com.simplicite.util.ObjectDirect] SIMPLICITE|https://e3m.simplicite.io:10163||ECORED0001|system|com.simplicite.util.ObjectDirect|save||Erreur ImmoFinancialElement
    java.lang.NumberFormatException: Character N is neither a decimal digit number, decimal point, nor "e" notation exponential mark.
     at java.base/java.math.BigDecimal.(BigDecimal.java:518)
     at java.base/java.math.BigDecimal.(BigDecimal.java:401)
     at java.base/java.math.BigDecimal.(BigDecimal.java:834)
     at com.simplicite.util.engine.DBAccess.setHost(DBAccess.java:751)
…

Alors que la validation du même formulaire en release ne génère pas d’erreur.
Merci d’avance pour votre aide.
Abed.

Instance en prerelease :

Instance en release :

Bonjour,

Ca semble venir d’un problème de host-value pour un champ bigdecimal.

  • quelle est le type de votre champ (float ? decimal long/big decimal, précision… ?)
  • et la valeur du champ saisi à l’écran ?

Il y a peut-être une subtilité dûe au changement de JDK 8=>12 sur les big decimals.
on va regarder

Merci @francois,

Le type de tous nos champs numériques est : décimale doubles (11,2)
voici le contenu des attributs du formulaire qui pose pb :

Je ne reproduis pas ce comportement en prerelease sur un champ de ce type. Avez vous testé d’autres objets avec un float ?

Je pense que votre formulaire poste un NaN dans la valeur d’un champ, il faudrait savoir lequel. Si c’est du code spécifique ou un champ dans un contexte particulier.

Il faut debugger la valeur de tous les attributs dans votre preSave pour voir quel numérique est faux
en ajoutant une trace this.toString() de l’objet.

A minima au preSave vous pourrez tester le NaN et forcer une valeur “”.
Si cela vient d’une anomalie socle dans un contexte particulier, on corrigera.

Merci @francois,
il y avait effectivement la valeur NaN dans deux attributs du formulaire. On dirait qu’en release, le socle force à 0 mais qu’en prerelease la valeur reste à NaN et génère une erreur.
J’ai mis des contrôle dans mon code pour qu’il n’y ait plus de NaN dans ces attributs.

Bonjour,

La UI n’est pas sensée mettre 0 si le champ est vide et facultatif, il restera null en base.
J’ai testé en release et prerelease, et je ne vois pas de problème mais le point reste à mieux qualifier.

Peux tu en dire plus sur ces 2 attributs ?

  • sont ils obligatoires/facultatifs, en lecture seule, invisibles… ?
  • ont ils du code spécifique en back ou front ?
  • d’où vient le NaN ? d’un calcul ? au moment du call ajax ?

Sans plus d’élément ont ne pourra pas reproduire donc corriger le cas échéant votre cas.

Bonjour @francois,

Les deux attributs sont facultatifs, en lecture seule et visibles.
Le NaN vient effectivement d’un calcul qui se fait dans le postValidate :

avant :

var c = this.getField("elemnFinanEvolTotBilan");
var evolTotBilan = 100*((elemnFinanTotBilanN - elemnFinanTotBilanN_1)/ Math.abs(elemnFinanTotBilanN_1));
c.setValue(evolTotBilan);	

Dans le cas où l’attribut elemnFinanTotBilanN_1 est vide, cette formule génère une erreur en prerelease et pas en release.

après ajout du contrôle ci-dessous, il n’y a donc plus de calcul si l’attribut elemnFinanTotBilanN_1 est vide, et donc plus d’erreur en prerelease) :

if (elemnFinanTotBilanN_1 != '' && elemnFinanTotBilanN_1 != 0){
  var c = this.getField("elemnFinanEvolTotBilan");
  var evolTotBilan = 100*((elemnFinanTotBilanN - elemnFinanTotBilanN_1)/ Math.abs(elemnFinanTotBilanN_1));
  c.setValue(evolTotBilan);	
} 

Certes, ce contrôle est nécessaire pour éviter une division par vide et générer un NaN, mais ce que je veux dire, ce que j’ai l’impression qu’en release, son absence ne pose pas de pb,