Developing.ru

Absurd, ты слишком категоричен в своих утверждениях. Нельзя делать общие выводы на основании частных посылок. Да, бывают ситуации, когда ловить исключения поздно, но обычно это не так. Кто мешает грамотному програмеру организовать свою кучу (хоть 20 куч) и запрашивать память из нее? Почему процесс должен умирать, если в приватной куче кончилась память? Даже если ты работаешь с кучей по умолчанию, почему отказ в памяти должен восприниматься как фатальная ошибка, вне зависимости от ситуации? А может, у меня другой поток через секунду освободит блок, и я, организовав опрос, получу требуемую память - ау, что ты там говорил про многопоточность?

Да, в Delphi объект-исключение создается в куче. Но много ли ему надо? В большинстве случаев размер запрашиваемого блока гораздо больше, и уж сгенерить exception памяти достанет. А в С++ исключение вообще вырастает на стеке.

Твой пример из Java оценить не могу, не компетентен. Но сам пишу на С# и особенности работы в 'песочнице' представляю. Если программа тихо умерла, возможны 2 варианта: 1) 'грамотные люди' все же где-то напортачили, или 2) редкая ситуация фатальной ошибки в виртуальной машине - и такое бывает. Но это не агрумент отказываться от exception handling.

В программе типа сервера БД я бы с самого начала выделял сколько памяти мне надо

А ты заранее знаешь, сколько программе надо? Особенно, типа сервера БД? Я-то всегда думал, для того умные люди и придумали разные хитрые штуки вроде кучи или сборки мусора, чтобы можно было выделять памяти сколько нужно, а не всю и заранее Этак мы возвращаемся во времена ДОС: "все мое - что хочу то и ворочу".

Короче, твой полемический задор мне понятен, я и сам люблю поспорить , но тут ты не прав.

Нельзя делать общие выводы на основании частных посылок.

Это называется 'индукция'

Даже если ты работаешь с кучей по умолчанию, почему отказ в памяти должен восприниматься как фатальная ошибка, вне зависимости от ситуации?

Как правило, непонятно что дальше делать.
В случае инициализации как правило если подсистему не ввести в действие то и другим подсистемам делать нечего.
Там и так всегда вагон запарок с кольцевыми зависимостями (логгер зависит от конфига, а конфиг от логгера etc).

Если мы имеем несколько потоков, каждый из которых периодически просыпается, делает одну и ту же работу, и засыпет, тогда можно конечно забить на работу в случае ошибки, заснуть и расчитывать что в следующий раз все будет успешно.

Можно в гуе ловить и давить все экзепшены. Нажал пользователь на кнопочку, никакого действия. Нажал еще - все заработало. Через год выснится что при нажатии на эту кнопочку при редком стечении обстоятельств возникает NullPointerException. Все залатают, дальше будет работать.

Я всегда проверяю наличие памяти. Только если начинаю рассчитывать, чего дают эти проверки, прихожу к выводу что скорее всего ничего не дают. Если не отвалюсь здесь, отвалюсь в другом месте. Может я не отвалюсь, но какая-нибудь библиотечка окажется менее живучей и отвалится. А потом я при обращении к любой функции этой библиотечки получу SEH экзепшен/сигнал. Если поместить любую современную программу в некую песочницу, и отвергнуть любой случайный ее запрос на память, с вероятностью 80% она осыпется с неким загадочным сообщением. Не забуду как древний фотошоп(4.0) строил внутреннюю базу данных на шрифты и при нехватке памати (2000+ шрифтов) вываливался с сообщением "Не могу открыть окно на этом экране" (Can't show window on this screen)

1) 'грамотные люди' все же где-то напортачили

Ну да, было желание сделать всю заливку данных атомарно (за одну транзанкцию). Причем объекту DAO данные шли в виде коллекции. Пришлось заливать по кусочкам, и обрабатывать ситуацию с не до конца залитыми данными.

А ты заранее знаешь, сколько программе надо? Особенно, типа сервера БД? Я-то всегда думал, для того умные люди и придумали разные хитрые штуки вроде кучи или сборки мусора, чтобы можно было выделять памяти сколько нужно, а не всю и заранее

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

Absurd, думаю, тема себя исчерпала.