On Sunday 12 September 2004 10:50, Jerry Feldman wrote:
On Sun, 12 Sep 2004 09:45:13 -0400
Agreed. Use the standard exception mechanism in C++. It is very flexible, and there should be very few reasons to use C style signals at all, but signals are supported by the language, and are portable to the extent that they are supported by the standards.
I'm specifically interested in what the OS might (try to) tell my program during execution. The article mentioned null pointer exceptions and divide by zero. The implication is that Microsoft Windows will throw such exceptions, as exceptions. I'm interested to know what might be done on Linux to achieve comperable behavior. One example that comes to mind is when my code was crashing for reasons I didn't understand, I wanted to wrap the call stack in a try catch to see what I caught. That's just the way things work in Java. If your program bails, you can be pretty sure it threw an exception when it did. Two things about C++ make the idea of catching and examining an exception in such cases a bad assumption. 1) There will likely be no exception thrown. 2) You cannot catch and examine an exception for which you don't know the type, and cannot recover the type through some kind of RTTI.
One of the primary differences is that a signal handler runs in a different context than does your regular code, whereas your exception handler runs within the program's context. I would not use antiquated with signals as signals are a lower level. C is essentially a medium level language somewhere between assembler and what we might consider a high level language.
I haven't dusted off my K&R to see what they have to say about