Что является основанием для того, чтобы не бросать
исключения в этих случаях? Это
Стандарт IEEE, или это был просто
Выбор дизайнерами Java?
Стандарт IEEE 754-1985 на страницах 20 и 21 в разделах 2.2.1 NAN и 2.2.2 Infinity четко объясняет причины, по которым значения NAN и Infinity требуются стандартом. Поэтому это не вещь Java.
Спецификация виртуальной машины Java в разделе 3.8.1 Арифметика с плавающей точкой и IEEE 754 утверждают, что при выполнении преобразования в целочисленные типы JVM будет применять округление до нуля, которое объясняет результаты, которые вы видите.
В стандарте упоминается функция с именем «обработчик ловушек», которая может использоваться для определения того, когда происходит переполнение или NAN, но в спецификации виртуальной машины Java четко указано, что она не реализована для Java. В разделе 3.8.1 сказано:
Операции с плавающей точкой
Виртуальную машину Java не выбрасывают
исключения, ловушка или другой сигнал
IEEE 754 исключительные условия
недопустимая операция, деление на ноль,
переполнение, недостаточное или неточное.
Виртуальная машина Java не имеет сигнализации
Значение NaN.
Итак, поведение не является неопределенным независимо от последствий.
Есть ли плохие последствия, что я
не зная, будут ли исключения
можно с такими слепками?
Чтобы ответить на этот вопрос, достаточно понять причины, изложенные в стандарте. Стандарт объясняет исчерпывающими примерами последствий, которые вы просите здесь. Я бы опубликовал их, но это было бы слишком много информации здесь, и примеры могут быть невозможно отформатировать соответствующим образом в этом инструменте издания.
EDIT
Я читал последний обзор технического обслуживания Спецификации виртуальной машины Java , опубликованной недавно JCP в рамках своей работы над JSR 924 и в разделе 2.11.14 под названием istructions для преобразования типов содержит дополнительную информацию, которая может помочь вам в поиске ответов, еще не то, что вы ищете, но я считаю, что это немного помогает. Там написано:
В сужающемся числовом преобразовании
значение с плавающей точкой в целое
тип T, где T либо int, либо long,
значение с плавающей точкой преобразуется
следующим образом:
- Если значение с плавающей запятой равно NaN, результатом преобразования будет
int или long 0.
- В противном случае, если значение с плавающей запятой не является бесконечностью,
значение с плавающей точкой округляется до
целое значение V с использованием IEEE 754
Округление до нулевого режима.
Есть два случая:
- Если T длинная и это целочисленное значение может быть представлено как длинная, тогда
В результате получается длинное значение V.
- Если T имеет тип int и это целочисленное значение может быть представлено как
int, то результатом является int
значение V.
В противном случае:
- Либо значение должно быть слишком маленьким (отрицательное значение большого
величина или отрицательная бесконечность),
и результат самый маленький
представимое значение типа int или
долго.
- Или значение должно быть слишком большим (положительное значение большой величины или
положительная бесконечность) и результат
является наибольшим представимым значением
введите int или long.
Сужающееся числовое преобразование из
double to float ведет себя в соответствии
с IEEE 754. Результат правильно
округляется с использованием IEEE 754 до
Ближайший режим. Значение слишком маленькое, чтобы быть
в виде числа с плавающей точкой преобразуется в
положительный или отрицательный ноль типа
плавать; слишком большое значение
в виде числа с плавающей точкой преобразуется в
положительная или отрицательная бесконечность.
двойной NaN всегда преобразуется в
поплавок NaN.
DНесмотря на то, что может произойти переполнение, потеря или потеря точности, сужение преобразований среди числовых типов никогда не заставляет виртуальную машину Java генерировать исключение времени выполнения (не путать с исключением с плавающей точкой IEEE 754).
Я знаю, что это просто повторяет то, что вы уже знаете, но у него есть подсказка, кажется, что стандарт IEEE требует округления до ближайшего.Возможно, здесь вы найдете причины такого поведения.
EDIT
Соответствующий стандарт IEEE в разделе 2.3.2 Режимы округления Состояния:
По умолчанию округление означает округление до ближайшего.Стандарт требует наличия трех других режимов округления;а именно, округление до 0, округление до + Infinity и округление до –Infinity.
При использовании с операцией преобразования в целое число округление до –Infinity приводит к тому, что преобразование становится функцией пола, тогда как округление до + Infinityявляется потолком.
Округление режима влияет на переполнение, поскольку при действии округления в направлении O или округления в направлении -Infinite переполнение положительной величины приводит к тому, что результатом по умолчанию будет наибольшее представимое число, а не + Infinity.
Аналогично, переполнения с отрицательной величиной приведут к наибольшему отрицательному числу, когда действует округление к + бесконечности или округление к О.
Затем они приводят пример того, почему это полезнов интервальной арифметике.Не уверен, опять же, что это ответ, который вы ищете, но он может обогатить ваш поиск.