4

I am writing a C++ library that uses an external third party C library. So my library will call functions in this third party library and the third party library will call back into a different part of my library.

I am wondering what happens to exceptions in this case? Say MyLib::foo() calls external C library function which eventually calls MyLib::bar(), and bar throws an exception, what happens? Will the exception be correctly propagated to a handler in foo() ?

Thanks!

aaa
  • 113
  • 1
  • 3

3 Answers3

6

Will the exception be correctly propagated to a handler in foo()?

I think whether exceptions propagate through external C code is undefined. What's even worse, the C code is unprepared and unable to handle the exception. C code doesn't need to immune against sudden, unexpected returns, so it knows no RAII etc.

When I was once faced with such a situation, I caught the exception before returning to the C API, stored it, and re-threw it once the call came back from the C API.

sbi
  • 219,715
  • 46
  • 258
  • 445
  • 2
    This is better than my answer. I didn't see that the third-party library was C rather than C++. Even though the questioner mentions this several times. Bedtime, maybe. – Tommy Herbert Dec 19 '10 at 22:21
  • This is the correct answer. While some implementations (GNU) go out of their way to try to allow exceptions to propagate across C code, it's a **very very bad** idea to make use of this. Not only is it non-portable, but there's no reason to assume the C code in between won't have inconsistent state or be holding memory allocations that haven't yet been recorded externally or freed. At best you're asking for memory leaks, and at worst, random crashes. I like sbi's suggestion of how to work around the problem, but it's probably best to avoid throwing exceptions across module boundaries at all. – R.. GitHub STOP HELPING ICE Dec 20 '10 at 01:54
  • 1
    @Tommy: I wrote lengthy explanation why letting exceptions propagate through a C lib is bad as a comment to your answer and became grumpy when you had already deleted it when I wanted to commit the comment. So thanks for your nice comment, which made up for this. `:)` – sbi Dec 20 '10 at 09:06
1

It is a heavy platform implementation detail. In general, the exception plumbing is somewhat likely to be able to unwind the stack through C function activation frames. Necessary because the CRT is often written in C. However, the C code is pretty unlikely to be happy about it, state got mutated that cannot be restored.

Just in case this is Windows, the C code does have a shot at it. C++ exceptions are piggy-backed onto the generic exception support built into Windows, called Structured Exception Handling (SEH). You use the __try and __except keywords to call an exception filter that can restore the C code state. Obviously this is not portable.

Never ask an implementation detail question without mentioning the implementation details, please.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
1

Read (and buy!) Herb Sutter's C++ Coding Standards

#62 : Don't allow exceptions to propagate across module boundaries.

Roddy
  • 66,617
  • 42
  • 165
  • 277