Por que você não pode pegar uma falha de segmentação em um manipulador de exceções?

p>p>signal(2) pode ser configurado para apanhar sinais SIGSEGV, que são os sinais gerados por uma falha de segmentação. Você pode configurar manipuladores de sinais para os outros tipos de erros de exceção em tempo de execução também, tais como SIGBUS (erro de barramento), SIGILL (instrução ilegal), e SIGFPE (exceção de ponto flutuante, ou coisas como dividir por 0).

Linux Signals and Traps

E muitas aplicações trapam os sinais acima, particularmente uma vez que eles são construídos em modo de produção. O único sinal que você não pode capturar é SIGKILL ou Signal 9; isto é para que seu aplicativo possa ser morto por um administrador ou pelo próprio SO se houver necessidade disso.

O problema é que uma vez que você pegou uma exceção indicando um mau estado de tempo de execução, não há muita coisa que você possa fazer. Algumas das memórias da sua aplicação são provavelmente corruptas, então retomar o processamento normal é provavelmente uma Má Ideia. Se você pegar a exceção, sobre tudo que você pode fazer é escrever uma mensagem de log FATAL no log do seu aplicativo, possivelmente enviar uma mensagem para o usuário se o aplicativo for interativo, fazer qualquer limpeza de fim de execução do aplicativo que você ouse tentar (enquanto está ciente de que estes podem acessar memória corrompida), e sair com um código de saída de erro.

Apesar do desenvolvimento, a maioria dos aplicativos não habilita o tipo de tratamento de sinal acima, já que os desenvolvedores preferem que o aplicativo "trave" imediatamente, então a razão do erro pode ser identificada e diagnosticada usando um depurador de memória e finalmente corrigida.