Почему целочисленные типы данных молча переполняются, а не вызывают исключение

Я узнал (по крайней мере, в java), что целые/длинные значения переполняются молча, и их значения начинаются с минимального значения при переполнении, а не вызывают какое-либо исключение.

Я использовал внешний API для некоторых файловых операций, в которых максимальный размер файла загружался из файла свойств. Все было хорошо в моей локальной тестовой среде. Как только код перешел в живую среду, ограничение максимального размера файла вообще не работало. После двух дней отладки/анализа кода не было никакого успеха. Затем по каким-то другим причинам я взял живой файл Constants.properties и отладил код с его помощью. о_0

Я просто хочу спросить, что мешало им выкинуть исключение при переполнении?


person Syed Aqeel Ashiq    schedule 14.04.2013    source источник
comment
Представление. Проверка на переполнение после каждой математической операции требует больших затрат. Для каждого добавления или умножения потребуется сравнение и ветвь.   -  person MTilsted    schedule 14.04.2013


Ответы (2)


Во многих случаях Java основан на C или C++, а они основаны на ассемблере. Переполнение/опустошение не происходит в C и C++ и почти бесшумно в ассемблере (если вы не отметите специальные флаги). Вероятно, это связано с тем, что C и C++ не имели исключений, когда они были впервые предложены. Если вы хотите увидеть переполнения/недополнения, вы просто использовали более крупный шрифт. например long long int или long double ;) Кстати, в сборке есть что-то похожее на исключения, называемые ловушками или прерываниями, переполнение / недополнение не вызывает ловушку, насколько я знаю.

Я предпочитаю использовать long и double, если только я не уверен, что эти типы намного больше, чем нужно. У вас не может быть устройства, размер которого превышает long.

person Peter Lawrey    schedule 14.04.2013
comment
You can't have a device which overflows long in size. Это утверждение стоит миллиона баллов, простой факт, который сначала не приходит на ум. Спасибо. - person Syed Aqeel Ashiq; 14.04.2013
comment
Возможно, однажды он появится и на Java, но размер файла должен быть более 9 миллиардов ГБ. - person Peter Lawrey; 15.04.2013
comment
Возможно, в те времена сегодняшними языками были бы ИТ. музеи. - person Syed Aqeel Ashiq; 15.04.2013
comment
Полегче с такими заявлениями! ;) Помните, что 640 КБ должно быть достаточно для всех? long может описывать размеры файлов/томов только до 9 экзабайт. Мало того, что Google сейчас работает где-то в этом диапазоне, это также всего в два миллиона раз больше, чем у текущих жестких дисков емкостью 4 ТБ. В два миллиона раз меньше этого была наша любимая дискета 3,5, которая была стандартным носителем данных всего 25 лет назад... Так что еще через четверть века одно видео Super-XUHD со стандартной камеры может запросто сломать вашу память. заявление. :) Java тоже может выжить так долго... Fortran и C выжили. - person Markus A.; 16.05.2014

Причина в том, что «так говорит Спецификация языка Java».

Раздел 4.2.2. Целочисленные операции JLS говорят:

Целочисленные операторы никоим образом не указывают на переполнение или потерю значимости.

Для меня это имеет смысл, иначе вам понадобится:

  • будет выброшено «NumericOverflowException», что потребует «поймать попытку», или
  • флаг, который будет установлен на примитивном результате, что потребует более сложной обработки примитивных операций

И то, и другое сделало бы примитивы и их операции «непростыми», а простота примитивов — это сила, которой не стоит жертвовать ради предсказуемого и обычно редкого случая.

person Bohemian♦    schedule 14.04.2013
comment
Хм? Почему минус? Чем этот ответ не помогает? (Этот ответ на самом деле правильный) - person Bohemian♦; 18.04.2013
comment
+1, к сожалению, сообществу SO иногда не нравится правда. - person Ingo; 30.10.2013
comment
Вопрос заключался в том, по какой причине язык был создан таким образом (отсюда и слово «почему»), указание на спецификацию не дает никаких рассуждений. - person Jake Hall; 30.12.2014