Catching a hot potato

[Gor Gyolchanyan]

Yeah, that's what i thought. If a segfault occurs, I am going to catch
it, but ONLY to restart the app right away. And I'm gonna save the
data constantly, so i'll have nothing to lose.

On Mon, Oct 17, 2011 at 10:03 PM, Marco Leise <Marco.Leise at gmx.de> wrote:
> Am 17.10.2011, 19:35 Uhr, schrieb Steven Schveighoffer
> <schveiguy at yahoo.com>:
>
>> 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
>
> If an application tends to crash (like a few versions of Delphi did), an
> auto-save feature will help. If you lose between 1-10 minutes of work at a
> maximum you can probably live with that. I don't think it is a shame if the
> application crashes when it is heavily plugin based. You just need to accept
> and consider that in the application design. OpenOffice has auto-save,
> Eclipse can restore previous installation states (i.e. before installing a
> plugin) etc.
>