I still hold the opinion that continuing to execute in any way at all, after program state has been corrupted, is dangerous. Especially if your crash handler does something like writing to a file.
If the world is whacked, who knows what might happen. It's like being on a psychedelic trip. You might think you're smelling roses when in fact you're stabbing someone in the chest.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
No, you're not. The thing is that message does not always mean an infinite loop. That same message is displayed whenever a program (on Windows specifically) derails be it access violations, infinite loops, divisions by zero and so on. It is a generic message displayed by Windows which, unfortunately, gives users very little information about what the problem may be. *nix based platforms at least dump some sort of error (hence the term segfault).
You're right. Which is why in the method I'm using the program doesn't continue to do anything. As soon as it crashes, that's it. The program is done. Instead, a separate program in a separate process which is monitoring the crashing program is what does the error reporting. At least that's how it works on the Win32 end. It does, however, switch to an error handler in the Mac build (not a mac programmer so I don't know if the error handler program I'm using could be ported to do something similar.)
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
That too -- single-threaded apps tend to do this if they're CPU intensive (programs like BSP compilers, for example).
So some other program catches the crash and scans out the backtrace from the dying process? Cool. On Mac, you could probably do something similar by forking your main process from a crash handler which ptrace()'s it. Since ptrace() intercepts all signal delivery, this is going to slow your process down whenever it receives a signal, but assuming it doesn't get signals very often it could be an acceptable method.
EDIT: Actually on Mac, maybe you'd use ktrace instead. I'm not an expert either.
Last edited by brewbuck; 03-14-2009 at 01:47 AM.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
That metaphor completely fails to make me see your point.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
That's nonsense. No matter how much a GUI program does, it should always prioritize (and thus handle in a timely manner) user interaction. Even if it is only to say, "Go away, I'm busy."
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
I would argue that for an event driven app this should be considered unacceptable.Originally Posted by brewbuck
Agreed. The so called 'error' may not be that of the vehicle but definitely of the driver. In this case, a program that is not responding due to being 'busy' is unaccetable behavior in any event-driven operating system (e.g., all modern OS's). Failing to respond is considered a badly behaved operating system and, in the good old days of Windows '95 (cringe), that sort of an application would often have the effect of bringing the entire OS to its knees which would force the user to restart their computer. It's one reason why programs are allowed to create separate threads -- throw the cpu heavy stuff in the one thread and respond to the OS with the main thread.Originally Posted by CornedBee
Thankfully modern OS's handle misbehaving applications in a better way (they tell you that the app is misbehaving and are prepared to kill it).
Last edited by leeor_net; 03-16-2009 at 05:55 PM.
That's what setting the cursor to the wait cursor (the hourglass) is for.
Very commonly for apps that otherwise respond just fine, someone somewhere will provide it more data than it can process in an acceptable amount of time, and cause it to become "not responding". I have a feeling that putting up the wait cursor stops that, but I could be wrong.
It's not always easy or even practical to process user input while you're busy.
Of course we should all try hard to keep our app responsive, for our users sake.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
It doesn't have to respond to everything I want, but it should at least allow me to exit, if I've accidentally started an operation that is going to take six hours to finish. Having an app go to la-la land with the only way to kill it being the task manager is just junk coding. Forcibly killing the app could corrupt data.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}