Perché non si può catturare un errore di segmentazione in un gestore di eccezioni?

Si può, in realtà...

signal(2) può essere impostato per catturare i segnali SIGSEGV, che sono i segnali generati da un segfault. È possibile impostare gestori di segnali anche per gli altri tipi di errori di eccezione runtime, come SIGBUS (errore di bus), SIGILL (istruzione illegale) e SIGFPE (eccezione in virgola mobile, o roba come dividere per 0).

Segnali e trappole di Linux

E molte applicazioni catturano i segnali di cui sopra, in particolare una volta che sono costruite in modalità di produzione. L'unico segnale che non potete catturare è SIGKILL o Signal 9; questo è così che la vostra applicazione può essere uccisa da un amministratore o dal sistema operativo stesso se c'è bisogno di farlo.

Il problema è che una volta che avete catturato un'eccezione che indica un cattivo stato runtime, non c'è molto che possiate fare. Parte della memoria della vostra applicazione è probabilmente corrotta, quindi riprendere la normale elaborazione è probabilmente una cattiva idea. Se prendete l'eccezione, tutto quello che potete fare è scrivere un messaggio di log FATAL nel log della vostra applicazione, eventualmente inviare un messaggio all'utente se l'applicazione è interattiva, fare qualsiasi pulizia di fine esecuzione dell'applicazione che avete il coraggio di provare (pur essendo consapevoli che questi possono accedere alla memoria corrotta), e uscire con un codice di uscita di errore.

Mentre è in fase di sviluppo, la maggior parte delle app non abilita il suddetto tipo di gestione dei segnali, poiché gli sviluppatori preferiscono che l'applicazione vada in "crash" immediatamente, in modo che la ragione dell'errore possa essere identificata e diagnosticata utilizzando un debugger di memoria e infine risolta.