>> Просто потому, что программа ещё может побороться за свою живучесть
> Уточним: она сможет лишь *непредсказуемо* *поглюкавить*. Забив на обработку проблемной
> ситуации. Т.к. если на проблемную ситуацию не было забито или же
> сбоев в логике работы вообще не было - тогда откуда взяться
> краху? Это ж лишь дефолтный обработчик вызываемый при обнаружении откровенно неправильной
> работы программы.try-catch в современных языках программирования никто не отменял. В блоке catch программа может определить неполадки и попытаться восстановить своё состояние до входа в блок try. В большинстве случаев такое поведение несмертельно для программы и позволяет продолжать её исполнение после выхода из обработчика исключительной ситуации.
Дебаты об исключениях: http://www.ibm.com/developerworks/ru/library/j-jtp05254/inde...
>> в рамках отведённых ей аппаратных ресурсов,
> Нюню. Если уж вы такой умный, то намекну: если система многозадачная, ресурсы
> в ней могут потреблять много программ сразу, прикиньте? И, кстати, это
> как билетная касса: у вас могут все разобрать перед самым носом.
Это — задача операционной системы и/или JVM. Пока что JVM показывает наилучшее управление ресурсами, чем, собственно, ядро ОС, глядя на то, как "текут картинки" и обваливается Xorg. :))
> В сях, кстати, для повышения надежности работы программы можно хапнуть себе приличный
> кус памяти *заранее*, поюзать его и никому не отдавать, далее юзая
> уже его (можно выделять память более гранулярно уже из этого куска).
<...>
> А на яве так сможете вообще? Или предполагается что Единственно Правильной логики
> встроенного аллокатора - хватит всем? ("совковая касса без услуги бронирования").
В JVM есть разные стратегии распределения памяти и уборки мусора. Под разные задачи можно выбрать оптимальные.
Краткая история развития технологии утилизации памяти: http://www.ibm.com/developerworks/ru/library/j-jtp10283/inde...
Исправление модели памяти Java, часть 2: http://www.ibm.com/developerworks/ru/library/j-jtp03304/inde...
Сборка мусора и производительность: http://www.ibm.com/developerworks/ru/library/j-jtp01274/inde...
> На
> сях кстати возможны и иные варианты логики - например периодические повторы
> попытки выделить память до успеха или таймаута считаемого фатальным, например. А
> на яве так сможете вообще? :)
А зачем в программе на Java выделять себе память? Массив нужного размера создался — хорошо — можно использовать его под буфер. Сам по себе объект имеет небольшой оверхед около 80 байт служебной информации и живёт, пока на него есть хотя бы одна ссылка. Лично я предпочитаю работать с долгоживущими объектами, которые изменяют своё состояние, если это нужно, а не создавать новые и новые объекты-"однодневки", которых прибирает GC.
