>В Linux нет дампа ядра? Оно сразу перезагружается? Хм... я видел реально серьезные сбои ядра всего несколько раз в жизни. И то - или в проприетарных драйверах или в экспериментальном коде. Что до сразу перезагружается - у нормального железа опять же есть (аппаратный и только так!) Watchdog Timer который вообще независимо от ОС вправит мозг системе аппаратным ресетом. Вообще невзирая ни на что если система перестала отвечать, например (и да, в линухе поддерживается целый выводок вачдогов). И это как раз тоже инструмент крашрекавери в батч-режимах, когда ресет нажать или девайс передернуть чисто физически некому.
>В Windows хотя бы Blue Screen Of Death есть — хоть что-то, что заставит посмотреть
>на экран и физически передёрнуть (humanable) "ручник".
Есть только одна проблема: если девайс стоит в датацентре за тридевять земель или в удаленном уголке планеты - передернуть девайс/питание/ресет может быть... НЕКОМУ. Или это может стоить нехилых баблосов или вести к большим потерям.
>Ага: "Программа выполнила недопостимую операцию и будет закрыто. Память не может быть
>Read." :)) Такое вот понятное каждому хомячку сообщеньице.
В винде кстати, особенно 9х оно требовало реакции юзера, что делало систему тотально не пригодной для работы в беспилотных режимах. Ну напримр если какая-то дрянь будет часто крешиться - в гуе возможно конечное число окон (9х выдерживает порядка 1-3 тысяч окон).В итоге система может сама себя ф#к%пнуть.
>вернув управление самой программе) или необрабатываемым ошибкам (тут уж за дело
>берётся ОС).
И что дальше? Если прога не обработала исключение и не ожидала подляну - дальнейшее уже ей не подконтрольно и о контролируемом крашрекавери спич уже не идет. Будет применен какой-то дефолтовый обработчик, со всеми вытекающими (как то потеря программой контроля над происходящим и какие-то дефолтовые действия по этому поводу, корректное выполнение программы будет нарушено). И, кстати, если память в системе закончилась - ява тоже не сможет ее родить, и посему любое действо ведущее к нужде выделить память завалится с исключением. Которое 99% прог сами не ожидают словить вообще, посему им тоже неизбежно настанет кирдык. Особенно если какойнить OOM killer не озаботится вопросом за чей счет освободить память.
>А вот для приложений C/C++ ничего "ниже" не существует — только Segmentation Fault.
Сложно быть тупым, да. Ващет это тоже дефолтовый обработчик. А если прога хочет - она может и сама проверить что *alloc вернул NULL и дальше что-то по этому поводу делать.
Но это фигня. На сях можно еще и вот так:
1) Заранее выделяем себе всю нужную нам память. Ну и как бы у нас ее уже не отберут и упасть при неудачной попытке выделения ессно не получится. Т.к. нет выделений памяти в рантайме. Вообще. Хоть это и несколько геморный вариант, он широко практикуется в эмбеддед, особенно в фирмварях работающих "без ОС" т.к. аллокаторов памяти там тупо нет никаких вообще. Си и это позволяет. И для критичных сервисов, фирмварей и прочая - оно очень даже. Поскольку подконтрольность выделения памяти - на высоте. А вот на яве так - слабо?
2) Я видел кастомные аллокаторы памяти которые не валятся сразу по поводу эпикфэйла при выделении памяти а ждут некоторое время и повторяют попытку выделить запрошенную прогрммой память несколько раз в надежде что проблемные условия пропадут и можно будет продолжить работу, что при штуках типа OOM Killer или каком-то мониторинге системы отстреливающем особо-жирные процессы вполне себе катит (прикольно, да?). В итоге прога притормозится в месте где пытались выделить память а когда память появится, прога дальше продолжит. Ну или если за разумное время памяти не появилось - объявить юзеру о том что у него говно в системе - гудбай, дескать. А на яве так слабо? :)
