vraiment un comportement étrange

Question

je le code suivant

if (msg.position == 0) 
    //removed for brevity 
else if (msg.position == txtArea.value.length) 
    //removed for brevity 
else { 
    //ERROR: should not reach here. 
    errorDivTag.innerHTML += msg.position + " " + txtArea.value.length; 
} 

Je vais avoir quelques situations vraiment bizarre où je reçois l'erreur dans le dernier bloc de code, mais les positions imprimées montrent que msg.position est en fait égal au txtArea.value.length. Cela ne se produit que 1% du temps, presque comme si j'avais une sorte de condition de course dans mon code où les deux ne sont pas égaux pendant la seconde instruction if, mais égales lorsque j'imprime dans le message d'erreur.

Des idées?

Answer 1

Pour commencer, utilisez toujours ===. Cela empêchera JavaScript de forcer automatiquement les types dans la comparaison, ce qui signifie que vous serez en mesure de repérer beaucoup plus facilement toutes sortes de bogues. Dans ce cas, il est possible que vous ayez des espaces (ce qui est fondamentalement impossible à voir dans la sortie) qui provoquent une comparaison de chaînes au lieu de la comparaison numérique souhaitée (je suppose).

En outre, je suppose que vous vouliez vraiment avoir { après vos conditions if et else if. Si ce n'est pas le cas, cela pourrait provoquer toutes sortes de comportements étranges, selon le code que vous avez supprimé pour des raisons de concision. Si vous n'avez pas, alors vous avez un étranger } avant votre condition else.

MISE À JOUR: Définissez un point d'arrêt dans Firebug/DeveloperTools/DragonFly/quelquechose et inspectez les valeurs lors de la comparaison.

Answer 2

Avez-vous essayez de changer la déclaration ...

parseInt(msg.position, 10) == txtArea.value.length 

Answer 3

=== est plus stricte que == et est souvent utile. Mais c'est le problème inverse de ce que vous avez ici, où quelque chose semble égal, mais n'est pas == ou === (si quelque chose n'est pas ==, ce ne sera jamais ===).

msg.position est une chaîne? Peut-être contient-il un espace ou un autre caractère similaire.

Answer 4

Si vous utilisez

parseInt(msg.position) 

sans radix, vous rencontrez des problèmes avec 08 et 09, parce qu'ils sont analysés comme des nombres octaux et donnant NaN. Toujours utiliser une base:

parseInt(msg.position, 10) 

Answer 5

J'ai eu ce problème aujourd'hui avec une valeur de total de contrôle dans l'un de mes modules js. Un test a montré que deux valeurs n'étaient pas égales, mais l'impression des valeurs a montré que étaient égales à.

Rantez-le dans le débogueur et (re-) découvrez que les types entiers dans Javascript sont des quantités flottantes de 64 bits. Un des nombres affichait comme négatif dans le débogueur - exactement (0xFFFFFFFF + 1) moins que l'autre nombre. D'une certaine façon, lorsqu'ils sont imprimés, ils sont affichés exactement les mêmes. J'utilisais une routine personnalisée pour les formater en hexadécimal, ce qui avait probablement quelque chose à voir avec ça. Cette combinaison de circonstances semble peu probable dans votre cas cependant.

J'ai découvert le problème de signe dans mon code en calculant le delta entre les nombres, et en l'affichant. Il est apparu comme MAX_UINT32 + 1, ce qui m'a rappelé que ces nombres sont vraiment des flottants de 64 bits.