JavaScript действительно странное поведение

Question

У меня есть следующий код

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;
}

У меня действительно странные ситуации, когда я получаю сообщение об ошибке в последнем кодовом блоке, но напечатанные позиции показывают, что msg.position фактически равно txtArea.value.length. Это происходит только в 1% случаев, почти как если бы в моем коде было какое-то состояние гонки, когда эти два НЕ равны во время второго оператора if, но равны, когда я печатаю в сообщении об ошибке.

Есть идеи?

Answer 1

Если вы используете

parseInt(msg.position)

без радиуса вы столкнетесь с проблемами с 08 и 09, потому что они анализируются как восьмеричные числа и дают NaN. Всегда используйте основание:

parseInt(msg.position, 10)

Answer 2

Для начала всегда используйте ===. Это предотвратит автоматическое приведение типов JavaScript в сравнение, что означает, что вы сможете намного легче обнаруживать все виды ошибок. В этом случае, возможно, у вас есть пробел (который в принципе невозможно увидеть в выводе), который вызывает сравнение строк вместо (я предполагаю) желаемого числового сравнения.

Кроме того, я предполагаю, что вы действительно хотели иметь { после ваших if и else if условий. Если нет, то это может вызывать все виды странного поведения, в зависимости от кода, который вы удалили из-за соображений краткости. Если вы этого не сделали, значит у вас есть постороннее } до вашего else состояния.

ОБНОВЛЕНИЕ : установите точку останова в Firebug / DeveloperTools / DragonFly / что угодно и проверьте значения во время сравнения.

Answer 3

У меня была эта проблема сегодня со значением контрольной суммы в одном из моих модулей js. Тест показал, что два значения не были равны, но печать значений показала, что они были равными.

Запустил его в отладчике и (повторно) обнаружил, что целочисленные типы в Javascript являются 64-битными плавающими величинами. Одно из чисел отображалось как отрицательное в отладчике - точно (0xFFFFFFFF + 1) меньше, чем другое число. Каким-то образом при печати они отображаются точно так же.

Я использовал собственную подпрограмму для форматирования их в шестнадцатеричном формате, что, вероятно, было связано с этим. Такое сочетание обстоятельств кажется маловероятным в вашем случае.

Я обнаружил проблему со знаком в своем коде, вычислив дельту между числами и отобразив ее. Он обозначался как MAX_UINT32 + 1, что напомнило мне, что эти числа действительно являются 64-битными числами с плавающей запятой.

Answer 4

=== более строгое, чем == и часто полезно. Но это проблема, противоположная той, что у вас здесь, где что-то выглядит одинаково, но не == или === (если что-то не ==, это никогда не будет ===).

Является ли msg.position строкой? Возможно, он содержит пробел или другой похожий символ.

Answer 5

Вы пытались изменить утверждение на ...

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