Обработать SIGSEV. http://www.visualdata.ru/blog/109-segv-signal.html

приогромнейшее спасибо

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

Если будут вопросы - обращайтесь :)

Согласен что в общем случае нельзя. Но. Довольно часто можно. Да и у пользователя появляется возможность попытаться сохранить не сохраненные данные например. Тут главное пользователя как следует предупредить об ошибке предложить перезагрузить программу и т.д.

лучше исправить программу

> продолжать работать дальше в общем случае сделать нельзя

Тут выбор между «сразу упасть» и «не упасть, если повезёт». Только надо уточнить: чтобы не упасть сразу, надо из обработчика SEGV выходить siglongjmp'ом.

на эту тему Луговский как-то хорошо высказался. посмотри в архивах ЛОРа, если интересно. А вообще такое приложение должно убиваться и как можно быстрее, а программисту, написавшему это приложение, которое try...catch (SEGFAULT), вместо исправления оного - отрывать руки.

>Обработать SIGSEV. http://www.visualdata.ru/blog/109-segv-signal.html

Доставляюще: «При переходе с паскаля (Дельфи) на C++/gcc (linux) я столкнулся с проблемой, что не могу отловить типичную ошибку Segmentation Fault. Хотя я скажу, что знал о этой проблеме давно, но только сейчас всерьез ей занялся.» (с) А на дельфях он значит AccessViolation херил try/catch'ем и считал, что все нормально?

> А на дельфях он значит AccessViolation херил try/catch'ем

Дельфи писали дураки по вашему...? В чем профит для пользователя, когда программа валится с не сохраненным документом, который набирался пол часа, например?

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

Как показала практика большинство AV - это обращение по нулевому указателю, что без последствий обрабатывается. Также стеки всех произошедших исключений логировались, что позволяло быстро находить ошибки и исправлять их. Писали сервер БД и приложений, отлаживались на клиенте :) В большинстве случаев клиент не замечал наших ошибок.

[Волшебным образом]Брюки превраща...

>Дельфи писали дураки по вашему...?

Казалось бы при чем тут те, кто писал Дельфи? Речь вроде вовсе о тех, кто его использует, не? Лень проверки делать - есть же try/catch. ;) Например, копится ошибка в обсчетах 3D сцены, переменные переполняются/теряют значимость, время от времени прога вылетает с «безобидной» ошибкой из-за кривой математики... Фиксить математику лень - есть всемогущий try/catch. Потом начинаются ошибки работы с дин. памятью... Ок. «Нет ничего проще!» (с) А некоторые вообще эксепшны для передачи сообщений запрягают. Этакий телеграф ядерными взрывами - круто, но «слегка» расточительно. (Ну или лодочный мотор: переплыть море, взрывая за кормой бомбы теоретически можно же. В GTA так танк разгоняют - на нем еще полетать можно, при желании.)

Хм, к чему все эти изречения? я где-то выше говорил что не надо исправлять ошибки?

Казалось бы при чем тут те, кто писал Дельфи?

В дельфях SEH реализован в компиляторе в VCL изначально и работает всегда. Казалось бы зачем они это сделали? Ява тоже не падает при делении на 0, пистон, в моей либе код дернут из gcj.

есть всемогущий try/catch

На самом деле try/catch как правило на всю программу один и находится он в основном цикле приложения, в нем отображается мессэджбокс юзеру.

А некоторые вообще эксепшны для передачи сообщений запрягают

Согласен - маразм.