>> В большинстве случаев такое поведение несмертельно для программы
> Ну так я уже сказал что если на ошибку положили болт -
> есть ровно 2 варианта что будет дальше: можно глюк обнаружить и
> убить программу. А можно не убивать и предоставить ей работать дальше.

Это только на сях имеют два выхода: segmentation fault или core dump — выбери из них лучшее. :)

> Только дальнейшее ее поведение будет неопределено. При том мне подход с
> пристреливанием при обнаружении потенциально фатального глюка как-то более симпатичен:
> способствует фиксингу этих самых глюков, а не предоставляет глюкастику глюкавить себе
> дальше в надежде что авось пронесет.

В своё время написал программу для обработки данных, которая пыталась несколько раз выполнить определённую функцию чтения и записи данные в базу данных. Операция чтения данных из файла была ненадёжна, так что с первого раза обычно не выполнялась, но выполнялась со второго-третьего-...-пятого раза, и данные в итоге записывались в базу данных за приемлемое время. Так как функция изначально работала с внешним файлом, который мог быть эксклюзивно занят на время обновления другой программой, то вероятность словить IOException была близка к 50%. Но моя программа просто обрабатывала это исключение, прогоняла заново операцию чтения и добивалась считывания данных из этого файла без каких-либо последствий для себя в режиме 24x7.

>> В JVM есть разные стратегии распределения памяти и уборки мусора.
> А *свою* стратегию - возможно подсунуть? Или как обычно - 640 Кб
> хватит всем, потому что умные дяди из сан/оракл так за вас
> решили?

Да, можно подсунуть свою реализацию GC. Код OpenJDK6 и API открыты. Если чувствуешь себя более умным, чем разработчики JVM, проблем не существует.

>Ну не malloc у вас сможет обломится, так new. И
> если скажем объект не создался и он был не для красоты
> - врядли получится корректно поработать дальше, правда? :) А 10 отличий
> - они в чем будут? Так, глобально? :)

Объекты в Java создаются атомарно. Если new не может создать объект, то вылетит исключение времени выполнения (или проверяемое исключение, если определено в сигнатуре конструктора) и его тоже можно обработать, можно корректно завершить программу.

>> предпочитаю работать с долгоживущими объектами, которые изменяют своё состояние, если
>> это нужно, а не создавать новые и новые объекты-"однодневки", которых прибирает GC.
> Ну да, конечно. Ведь с new но без delete при активном создании
> объектов поиметь неочевидные утечки памяти - ни разу не проблема, правда?
> :))) Ведь достаточно оставить по недосмотру ссылку на какой-то временный объект,
> и GC его уже никогда не убьет. И будет .... утечка
> памяти! Та самая, которая якобы "невозможна" на яве, хи-хи ;).

Какие мы глупые! У нас нет профилировщика, чтобы анализировать сколько и каких объектов создаётся и не убирается во время работы нашей программы! Хи-хи. :))