Catching a hot potato

[Steven Schveighoffer]

On Mon, 17 Oct 2011 13:21:39 -0400, Norbert Nemec  
<Norbert at nemec-online.de> wrote:

> On 17.10.2011 14:54, Steven Schveighoffer wrote:
>> Your best bet is to close the application, and possibly print a stack
>> trace. Trying to continue is like continuing to drive when you get a
>> flat tire. You are just going to keep damaging your car!
>
> To stick with this nice analogy:
>
> Trying to recover fully from a segfault is indeed like continuing to  
> ride with a flat tire. Bad idea!
>
> Accepting the system default segfault handling is like abandoning the  
> whole valuable truckload just because of a flat tire. Not such a good  
> idea either.

Oh, well, that's up to the application design.  I once designed a system  
backed by a database that could be restarted and using the data in the  
database could pick up exactly where it left off.  You could call this the  
AAA of application recovery :)

In many cases, the "valuable truckload" of an application is quickly and  
easily recreated.

> Sure, an emergency save may fail because of the memory corruption, but  
> there is a very good chance that it still works because the essential  
> data structures happen to be unaffected.

Or there's a chance it saves corrupted data, and screws your entire  
database, or whatever.  It all depends on the situation.  Is it  
recommended not to catch segfaults?  Definitely.  Should you ever do it?   
Maybe, but don't rely on the resulting data for mission critical  
applications.  The only reason I can see to continue is to try and debug  
the issue, not to continue running the program.  You're better off  
designing your application to recover via restarting.

-Steve