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

У меня есть следующий кодJavascript действительно странное поведение

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, но равны, когда я печатаю в сообщении об ошибке.

Любые идеи?

источник

2010-05-28 Martin Konecny

Что такое 'msg.position' (в тех редких случаях)? В частности, запишите 'typeof'. – Bergi

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

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

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

источник

2010-05-28 16:59:25

С этого момента я буду использовать оператор '===', к сожалению, он не решил проблему в этом случае. А в случае скобок у меня есть только одна строка после блоков «if» и «elseif». –

Вы пытались добавить переменную, чтобы сохранить значение 'txtArea.value.length'? Это должно устранить любые проблемы, связанные с изменением ценности между сравнением и отладочной печатью. –

Подождите, у вас есть только одна строка (без фигурных скобок) на ваших 'if' и' else if', но у вас есть закрывающая скобка перед последним 'else'? Похоже, что это может привести к тому, что ветвление произойдет иначе, чем вы ожидаете. Вы можете проверить это. – jhurshman

ли попытаться изменить заявление ...

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

источник

2010-05-28 17:00:19 davydotcom

У меня есть код 'msg.position = parseInt (msg.position);' чуть раньше, чем предоставил код. –

@teehoo: Вы также должны передать параметр ', 10' в' parseInt', поэтому число не ошибочно принимается за восьмеричный/шестнадцатеричный номер. (Без этого параметра IIRC, ведущий ноль в строке, приведет к тому, что число будет интерпретировано как восьмеричное.) –

ok - любой из этих кодов, вызываемых функцией setTimeout вообще? Это действительно единственный способ, когда состояние гонки может возникать в javascript, если вообще. – davydotcom

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

Is msg.position a String? Возможно, он содержит пробел или другой подобный символ.

источник

2010-05-28 17:17:54 jhurshman

Если это строка, то '===' покажет этот факт. Это мое любимое преимущество использования. –

msg.position создается с использованием 'msg.position = parseInt (msg.position, 10);' перед примером кода. –

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

parseInt(msg.position)

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

parseInt(msg.position, 10)

источник

2010-05-28 17:19:02 Magnar

Я никогда не знал этого. Однако в этом случае не поможет. –

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

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

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

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

источник

2010-05-28 18:02:07 Cheeso

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

ответ

Смежные вопросы