OS C++ Exception interoperation?
Is there a similar facility in Linux for exception "exception registration"? http://www.codeproject.org/cpp/exceptionhandler.asp#xx515459xx For this discussion, I will consider exceptions to be those that are explicitly thrown or occur due to conditions like divide by zero or null pointer access. When exception occurs, interrupt is generated and control is transferred to the operating system. Operating System, in turn, calls the exception handler that inspects the function call sequence starting from the current function from where the exception originated, and performs its job of stack unwinding and control transfer. We can write our own exception handler and register it with the operating system that it would call in the event of an exception. Windows defines a special structure for registration, called EXCEPTION_REGISTRATION: -- Regards, Steven
Is there a similar facility in Linux for exception "exception registration"? http://www.codeproject.org/cpp/exceptionhandler.asp#xx515459xx
For this discussion, I will consider exceptions to be those that are explicitly thrown or occur due to conditions like divide by zero or null pointer access. While I'm not 100% familiar with the internals of exception handling in C++ and Java on Linux, asynchronous behavior is delivered to processes by the signal mechanism. The process sets up a signal handler, and upon
On Fri, 10 Sep 2004 19:11:52 -0400
"Steven T. Hatton"
On Friday 10 September 2004 20:46, Jerry Feldman wrote:
On Fri, 10 Sep 2004 19:11:52 -0400
"Steven T. Hatton"
wrote: Is there a similar facility in Linux for exception "exception registration"? http://www.codeproject.org/cpp/exceptionhandler.asp#xx515459xx
For this discussion, I will consider exceptions to be those that are explicitly thrown or occur due to conditions like divide by zero or null pointer access.
While I'm not 100% familiar with the internals of exception handling in C++ and Java on Linux, asynchronous behavior is delivered to processes by the signal mechanism. The process sets up a signal handler, and upon the receipt of that signal, the OS then delivers it to the process. The try-catch mechanism is a language specific mechanism. The language, in this case C++, generates the appropriate code for the target OS and processor. Stack management and unwinding is generally performed by the language.
I really didn't think very hard about the topic before I posted. I immediately realized it was potentially important, and wanted to call it to the attention of others. You are correct in bringing up signals. My understanding is, the way traditional Java deals with null pointer access is by checking all access for you. It (the JVM) /is/ the OS. I wonder how the GNU Java compiler deals with exception handling? I really don't know how Unix signals affect the execution of my C++ programs - other than the fact they crash when receiving SIGSEGV. I guess the signal handling is part of the gcc implementation. So the mechanism for "exception registration" would need to be part of the compiler implementation. It would be nice to have such functionality defined in a platform-independent way. In order for something like this to work, the signal would have to cause an exception to be thrown to the errant function, or at least from that function. I think I might post this to the GCC mailing list. -- Regards, Steven
On Sat, 11 Sep 2004 20:46:47 -0400
"Steven T. Hatton"
I really didn't think very hard about the topic before I posted. I immediately realized it was potentially important, and wanted to call it to the attention of others. You are correct in bringing up signals. My understanding is, the way traditional Java deals with null pointer access is by checking all access for you. It (the JVM) /is/ the OS. I wonder how the GNU Java compiler deals with exception handling?
I really don't know how Unix signals affect the execution of my C++ programs - other than the fact they crash when receiving SIGSEGV. I guess the signal handling is part of the gcc implementation. So the mechanism for "exception registration" would need to be part of the compiler implementation. It would be nice to have such functionality defined in a platform-independent way.
In order for something like this to work, the signal would have to cause an exception to be thrown to the errant function, or at least from that function. I think I might post this to the GCC mailing list.
Theoretically, a program written in C++ that adheres to the C++
standards should be portable, but we all know that various systems tend
to add "features". C++ also supports signals. There are also standard
exceptions that are defined in C++. (Look at the header file stdexcept).
But, in any case, there is a catch all clause.
--
Jerry Feldman
On Sunday 12 September 2004 08:16, Jerry Feldman wrote:
On Sat, 11 Sep 2004 20:46:47 -0400
Theoretically, a program written in C++ that adheres to the C++ standards should be portable, but we all know that various systems tend to add "features". C++ also supports signals. There are also standard exceptions that are defined in C++. (Look at the header file stdexcept). But, in any case, there is a catch all clause.
Looking over the ISO/IEC 14882:2003 discussion on signals I have the
impression that signals and exceptions are intentionally placed on either
side of the C/C++ fence. The support for signal handling in C++ is inherited
from
On Sun, 12 Sep 2004 09:45:13 -0400
"Steven T. Hatton"
Looking over the ISO/IEC 14882:2003 discussion on signals I have the impression that signals and exceptions are intentionally placed on either side of the C/C++ fence. The support for signal handling in C++ is inherited from
of C. It seems pretty clear that any signal handling that would involve exceptions is "implementation defined". I would prefer to avoid implementation defined features as much as possible. OTOH, it would be nice if I could catch an exception when my program received some kind of signal. This seems to be one of the many damned if you do, damned if you don't
dilemmas of C++. If you do implement signal handling with exceptions, it breaks the C compatability objective. If you don't use exceptions you end up with C-style antiquated signal handling. 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.
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.
--
Jerry Feldman
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
I haven't dusted off my K&R to see what they have to say about
. I'm not completely sure what you mean by running in a different context. Very specifically, a signal handler does not share the same stack as the
One thing I started thinking about is what situations might result in signals being sent to my program during execution. The big one that comes to mind is stepping into someone else's memory space. I guess I could try to come up with a strategy that checked for a signal as part of the execution of certain types of calls. But that sounds like a lot of overhead. I'm a bit rusty on C++, but you can set up an exception handler to catch
On Sun, 12 Sep 2004 18:03:56 -0400
"Steven T. Hatton"
On Sunday 12 September 2004 19:18, Jerry Feldman wrote:
On Sun, 12 Sep 2004 18:03:56 -0400
"Steven T. Hatton"
wrote: I haven't dusted off my K&R to see what they have to say about
. I'm not completely sure what you mean by running in a different context. Very specifically, a signal handler does not share the same stack as the main program. it is very similar to an interrupt handler.
Almost like a separate thread. I guess it just sits there at the global level doing nothing until a throw causes the instruction pointer to branch to its entry point. I've notice nm show U _Unwind_Resume@@GCC_3.0 at the top of all the programs I've looked at. I assume that represents the entry address of the exception handler.
I'm a bit rusty on C++, but you can set up an exception handler to catch this type of exception.
C++ exception handling is, uh, interesting. Yes, you can switch out the exception handler, and you can also catch exceptions you threw from the same function, and throw them again, and again, and again......... ^C.
In essence, a divide by zero exception would result in a termination unless you specifically set up an exception handler for this.
But you have to have an exception to catch first. I'm fairly certain C++ does not generate an exception when you call a divide by zero. That's why I'm interested in the article. What it seems to amount to is OS calls to Windows are 'native C++'. Or something like that.
Java is a much different environment in that the language does not have a legacy signal mechanism. In Java, the signal from the OS is delivered to the JVM which then delivers it as an exception to your application.
Java's got it's good points. Are you using JBuilder? -- Regards, Steven
Almost like a separate thread. I guess it just sits there at the global level doing nothing until a throw causes the instruction pointer to branch to its entry point. I've notice nm show U _Unwind_Resume@@GCC_3.0 at the top of all the programs I've looked at. I assume that represents the entry address of the exception handler. Conceptually yes. In C, signals are caused by either some external circumstance, such as the user using the kill(2) command, or by a
On Mon, 13 Sep 2004 03:24:59 -0400
"Steven T. Hatton"
On Mon, 13 Sep 2004 03:24:59 -0400
"Steven T. Hatton"
C++ exception handling is, uh, interesting. Yes, you can switch out the exception handler, and you can also catch exceptions you threw from the same function, and throw them again, and again, and again......... C++ (and Java) exception handling uses a different paradigm than does C signals:
try {
code causing exceptions
.....
} catch(exception &e) {
The exception caused the code to branch here.
} ... more catch clauses
The exception handler runs in the same context as the process. In
effect, the compiler registers the catch clauses at the beginning of the
try block, so that when an exception occurs the program counter would be
adjusted to point to the handler. If no exceptions occur, the end of the
try block would cause the program to branch to the instruction following
the catch clauses. If an exception is not caught in the current context,
it is passed up the line, either terminating the program or transferring
control to a higher level try block. That way if a function throws an
exception, the stack would be unwinded to the calling function. If that
is within a try block, then the transfer would go to the appropriate
catch or further passed up the line.
--
Jerry Feldman
participants (2)
-
Jerry Feldman
-
Steven T. Hatton