Sean Kelly wrote:
Tomas Lindquist Olsen Wrote:
On Tue, Nov 17, 2009 at 11:51 AM, Walter Bright
<newshou...@digitalmars.com> wrote:
I suppose nobody much cares if it writes out a corrupted audio file. People
care very much if their airplane suddenly dives into the ground.
Be that as it may, it is certainly possible to catch seg faults in an
exception handler and write files out. That would be an unacceptable
behavior, though, in a system that needs to be safe.
You spent quite a bit of effort explaining that segfaults never cause
memory corruption, so it seems fairly reasonable to assume that some
parts of the application state could still be valid and useful not to
throw away.
At the moment the segfault occurs, sure. But if the process eats the segfault
and continues, what happens? If an app is programmed in such a way that
segfaults are a part of normal processing (I worked on a DB that performed
dynamic loading this way) that's one thing. But other apps are almost
definitely going to try and write data near 0x00 after such an occurrence.
I think throwing an Error object instead of failing immediately would be
occasionally useful. (Same goes about other trapped errors such as
integral division by zero.) There are applications out there that want
to partially recover from a null pointer error. I wrote a few, so it's
difficult to convince me they don't exist.
Andrei
