How C++ Exception handling works ?

[Subhransu Sekhar Sahoo]

Hi All,

I have a doubt in the implementation of C++ try catch exception handling
procedure. Whenever there is a through, the execution has to go to the point
of catch. Now, if the catch block resides across DLL boundary (i.e. The
Catch block is there in another DLL). In that case the compiler can not put
the code for jumping to the catch point. What I think is that there needs to
be some explicit support from the OS that would maintain the try/catch block
in the kernel context and the compiler will get the jump context from the
OS. In that case a C++ compiler (Supporting exception handling) can't be
written for an OS which doesn't natively support C++.

I am totally confused and i have no clue how try/catch can be implemented.

Pls explain if anyone knows how it works.


Regards,
Sahoo

 

[Alf P. Steinbach]

* Subhransu Sekhar Sahoo:

I have a doubt in the implementation of C++ try catch exception handling
procedure. Whenever there is a through, the execution has to go to the point
of catch. Now, if the catch block resides across DLL boundary (i.e. The
Catch block is there in another DLL). In that case the compiler can not put
the code for jumping to the catch point.

Whatever made you think that a 'throw' is implemented as a direct jump?
'throw' is dynamic. Where it ends up depends on the call context.

 

[Jacek Dziedzic]

Hi All,

I have a doubt in the implementation of C++ try catch exception handling
procedure. Whenever there is a through, the execution has to go to the point
of catch. Now, if the catch block resides across DLL boundary (i.e. The
Catch block is there in another DLL). In that case the compiler can not put
the code for jumping to the catch point. What I think is that there needs to
be some explicit support from the OS that would maintain the try/catch block
in the kernel context and the compiler will get the jump context from the
OS. In that case a C++ compiler (Supporting exception handling) can't be
written for an OS which doesn't natively support C++.

I am totally confused and i have no clue how try/catch can be implemented.

Pls explain if anyone knows how it works.

That does not answer your question, but you generally want
to avoid exceptions propagating across module boundaries altogether.

- J.

 

[Shark]

That does not answer your question, but you generally want

to avoid exceptions propagating across module boundaries altogether.

- J.

Is this a result of how compilers handle exceptions, or are there any
other reasons for doing so?
I am curious to know whether a C++ program knows about module
boundaries.

 

[Roland Pibinger]

I am totally confused and i have no clue how try/catch can be implemented.
Pls explain if anyone knows how it works.

http://www.codeproject.com/cpp/exceptionhandler.asp

Best wishes,
Roland Pibinger

 

[Ian Collins]

Hi All,

I have a doubt in the implementation of C++ try catch exception handling
procedure. Whenever there is a through, the execution has to go to the point
of catch. Now, if the catch block resides across DLL boundary (i.e. The
Catch block is there in another DLL). In that case the compiler can not put
the code for jumping to the catch point. What I think is that there needs to
be some explicit support from the OS that would maintain the try/catch block
in the kernel context and the compiler will get the jump context from the
OS. In that case a C++ compiler (Supporting exception handling) can't be
written for an OS which doesn't natively support C++.

DLLs are Windows specific, maybe you would be better of asking in a VC++
group.

Every compiler has its own mechanism, so there is no standard explanation.

 

[Ian Collins]

Is this a result of how compilers handle exceptions, or are there any
other reasons for doing so?
I am curious to know whether a C++ program knows about module
boundaries.

Standard C++ has no concept of module boundaries, it's a concept
specific to one OS.

 

[Dakka]

Hi All,

I have a doubt in the implementation of C++ try catch exception handling
procedure. Whenever there is a through, the execution has to go to the point
of catch. Now, if the catch block resides across DLL boundary (i.e. The
Catch block is there in another DLL). In that case the compiler can not put
the code for jumping to the catch point. What I think is that there needs to
be some explicit support from the OS that would maintain the try/catch block
in the kernel context and the compiler will get the jump context from the
OS. In that case a C++ compiler (Supporting exception handling) can't be
written for an OS which doesn't natively support C++.

I am totally confused and i have no clue how try/catch can be implemented.

Pls explain if anyone knows how it works.


Regards,
Sahoo

How can the catch block reside across a DLL boundary? Anyway, this is an
implementation detail and has *nothing* to do with the language
support. Have you tried to test this assertion?

 

[Risto Lankinen]

I am totally confused and i have no clue how try/catch can be implemented.

Pls explain if anyone knows how it works.

There are many ways. Here's one in a nutshell:

To implement exception infrastructure, the compiler creates
an exception record for every function (and statement block
and often also for a "virtual block" which is when a complex
declaration appears in the middle of a statement block and
therefore requires an augmentation to the cleanup routine) that
it compiles. This record contains pointers to the beginning
and end of each block's code, and a pointer to the code that
cleans up the stack when exiting the block.

To compile "catch", a new field is added to the innermost
containing exception record that indicates the entry point of
the catch routine, and a descriptor which encodes the type
of exception object being caught.

To compile "throw", a run-time library routine will be called
that [1] locates the active exception record (this can be done
because the location of "throw" will be within the beginning-of
and end-of addresses of exactly one function), [2] sees if that
record has a catch-handler for the thrown type and depending
on that, [3a] calls the catch handler, or [3b] calls the block's
stack cleanup code and restarts from [=>1] using the next
highest return address in the stack as the "location of throw".

Brief consideration of DLL's [otherwise a non-C++ topic]:
The throw-handler is necessarily on a "lower" level than the
application code. For a stand-alone application the minimum
level is run-time library. For a dynamically linked application,
it is necessary to put the handler into the same level with the
module loader and give it access (perhaps thru import/export)
to all modules' exception records.

- Risto -

 

[Shark]

Standard C++ has no concept of module boundaries, it's a concept

specific to one OS.

What about cases in which you mix C and C++ code? C++ runtime libraries
are different from C-specific (I could be wrong), but you can treat
them as two different entities equvalent to modules. Lets say a C
program calls a C++ function, and this C++ function is designed to
throw an exception!

 

[Ian Collins]

What about cases in which you mix C and C++ code? C++ runtime libraries
are different from C-specific (I could be wrong), but you can treat
them as two different entities equvalent to modules. Lets say a C
program calls a C++ function, and this C++ function is designed to
throw an exception!

If it was designed to throw exceptions, then it shouldn't be given
extern "C" linkage. But I see your point, an exception could bubble up
from within the C++ code.

I'd guess we are straying into undefined behaviour here, seeing as C has
no concept of exceptions. Some exception implementations would work in
a C++ calls C which calls C++ situation, others would not.

Interesting side question though: should extern "C" implicitly add
throw() to the prototype thus triggering unhanded if an exception is thrown?

 

[Larry I Smith]

http://www.codeproject.com/cpp/exceptionhandler.asp

Best wishes,
Roland Pibinger

An interesting article - if you're using MS VC++ on Windows...

Regards,
Larry

 

[Jacek Dziedzic]

Standard C++ has no concept of module boundaries, it's a concept
specific to one OS.

What I meant to say (or rather to quote) related to modules
in a "programming engineering" sense. I was just reading this
Sutter/Alexandrescu book and Rule#62 said
"Don't let exceptions propagate across module boundaries".

I can back-translate to English the synopsis of this for you:

"You shouldn't throw pebbles into your neighbour's garden.
There is no such thing as a binary level standard of
exception handling. Therefore you should not let exceptions
propagate across modules, unless you are able to make sure
that all compiler 'set and setting' are identical for both
parts. If you can't guarantee that, the modules may handle
exceptions in a non-interoperable manner and there will be
no monolithic way of propagating exceptions. Therefore it
should be stressed that "thou shalt not allow for exceptions
to propagate across modules and subsystems"".

For more info try this book, it will be called "C++ coding
standards" or something similar (again, I only have a translation).
It was recommended by BS himself.

HTH,
- J.