makhaonBlazkowicz,

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

Так и в том же Delphi так же :) Пока не прямо в среде, правда. Но внешних тулов несколько штук есть. Которые именно так же - перехватывают, обрабатывают, логгируют, и даже сами логи шлют куда настроено.

Просто в теме активно продвигается мнение о том что управляемые языки более надежны, чем неуправляемые. А оказывается - что "болезнь стандартная для многих языков".



Управляемые языки - это прежде всего управление памятью, что дает более предсказуемое поведение (контроль выхода за пределы массива например) и автоматическая сборка мусора. Никаких чудес это не делает, просто избавляет от головняка, который возникает в unmanaged средах исполнения.


По стек-трейсам JVM проблема диагностируется в 95% случаев без отладчика/трассировщика.

Поди узнай, что случилось, когда юзер говорит: Мне тут прога пишет "Access violation at address 00AF093E in module 'zalepooha.exe'. Read of address 000000EF" Чтобы дорытся до проблемы, надо всякие gdb/strace/ltrace пользовать, что на стороне клиента далеко не всегда можно сделать, а у разработчика ошибка может тупо не повторяться (окружение разное, фаза луны там)

makhaonBlazkowicz,

авторAccess Violation это гарантированная смерть процесса в unmanaged среде.

Совсем не обязательно. Можно восстановиться.

авторпрокладка между стулом и монитором совершенно не при чем

Прокладка всегда причем.

авторПроцесс от смерти оно спасает?

'прокладка' может спасти от смерти процесс.

авторконтроль выхода за пределы массива например

Range check делает то же самое. Само собой - небесплатно (в смысле времени). Всегда можно включить на время бета-тестов. Что мы, обычно, и делаем. В релизе же отключить, что бы не время не занимало.

авторМне тут прога пишет "Access violation at address 00AF093E in module 'zalepooha.exe'. Read of address 000000EF"

Это уже лет 10 как прошлый век :) колл-стэки и окружение давно и успешно снимаются полностью автоматически.

Ну поздравляю! Управляемый код во все поля))) GC небось тоже есть?))

makhaondimonz80,

Сборщик мусора в дотнете, к слову, та еще заноза. Мы как-то часть функциональности выносили в повер шелл, который работает 'над' дотнетом. В результате сервер на делфи 'коптил', как обычно, занимая минимум памяти, принимая и сохраняя файлы. Скрипты же, занимавшиеся простым копированием файлов, отъедали всю память так, что система просто уходила в даун.
Но виноват, конечно же, не gc, а прокладка.


авторНо виноват, конечно же, не gc, а прокладка - ну вот, сами все понимаете!))

makhaondimonz80,

авторНу поздравляю! Управляемый код во все поля)))

:) причем без лишних прокладок с системой.

ИМХО неа! Есть рантайм - есть прокладка. Чем больше контролирует рантайм - тем жирнее прокладка. JVM дает жирнющщщщее окружение (сравнимое разве что с ОС), что дает очень большой задел для контроля сложности.
В делфи похоже можно собирать свой конструктор из менеджеров памяти и т.п. 10 правило Гринспена для делфи)))