Здравствуйте, _hum_, Вы писали:
EP>>Почему эта мифическая угроза заставляет ловить везде исключения, но при этом не заставляет проверять NaN-ы?
__>

__>if(1 == f())
__>{
__>   do_something();
__>}
__>

__>в случае с "NaN" никаких доп. проверок делать не нужно. в случае с эксепшеном обязательно надо ставить трай-катч

а в таком случае?

if(f() > 0)
   do_something();
else
   do_something2();

удобно сразу стало, да, иметь Nan ?

Здравствуйте, _hum_, Вы писали:
EP>>Почему эта мифическая угроза заставляет ловить везде исключения, но при этом не заставляет проверять NaN-ы?
__>

__>if(1 == f())
__>{
__>   do_something();
__>}
__>

__>в случае с "NaN" никаких доп. проверок делать не нужно. в случае с эксепшеном обязательно надо ставить трай-катч

а в таком случае?

if(f() > 0)
   do_something();
else
   do_something2();

удобно сразу стало, да, иметь Nan ?

если вы допускаете Nan, то, например, даже две корректные реализации поиска максимального элемента массива могут дать разные результаты. вам нужны nan-proof версии всего когда, использующего сравнения < >

то же самое с сортировками

при введении Nan вы либо откалываетесь от всех сравнений <, либо пишете проверку на nan перед каждым таким сравнением. стало сразу удобно, да? только школьник-жапоскриптер может испытывать удобства от наличия Nan, ваяя свой спагетти говнокод