Andrei Alexandrescu Wrote: > 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.
I'd love to! And this is how Windows works. But throwing an exception from a signal handler invokes undefined behavior. Last time I googled this I saw as many accounts of it failing horribly as working.