0

I am compiling my program with a 3rd party library. That library contains an error callback if an error occurs internally. Inside that error callback I am throwing an exception and I have a unit test to verify that when I do something invalid that the exception is thrown. This all works beautifully in Windows, but when I test this in linux (fedora) I am getting an abort from an uncaught exception.

I tried wrapping my call directly with a try-catch block but no luck. ( Also, all my code is running within the google test framework which also normally catches exceptions ). The only thing that seems to catch the exception is if I wrap the throw statement in a try block directly within the error callback.

Does anyone have any idea why this would happen and if there is a way to catch the exception?

drewag
  • 93,393
  • 28
  • 139
  • 128

2 Answers2

3

When you interface with third-party libraries you usually have to catch all exception on the border between your code and their code:

int yourCallback( params )
{
    try {
      doStuff( params );
      return Okay;
    } catch (...) {
      return Error;
    }
}

The reason is you can't be sure that library is written in C++ or it uses the very same version of C++ runtime as your code uses.

Unless you're completely sure that code can deal with your exceptions you can't propagate exceptions to third-party code. The extreme example is COM where both your code and "other code" can be in whatever language and with whatever runtime and you are not allowed to let exceptions propagate through COM boundary.

Community
  • 1
  • 1
sharptooth
  • 167,383
  • 100
  • 513
  • 979
1

Usually you should not throw exceptions "through" code you do not know anything about. It might be C code, which will not even clean up after itself.

How to deal with your concrete problem would require concrete information about the 3rd-party library you are interfacing with. What is that callback there for? To give you a chance to fix stuff? To inform you that an error occurred? Can you cancel whatever operation it is called from?
One way to deal with such a scenario is to store some information somewhere when the callback is called and check for that information when the actual processing finishes from your function that calls into that library.

sbi
  • 219,715
  • 46
  • 258
  • 445
  • I think this is almost definitely the problem. It is a C library. However, I guess I am just confused why Windows could handle it and Linux doesn't? – drewag Jun 06 '11 at 14:37
  • @drewarg: Whatever the reason is you shouldn't depend on it - please take time to read the answer to the question I link to. – sharptooth Jun 06 '11 at 14:38
  • @drewag: I wouldn't know. But throwing C++ exceptions through C code is likely to be invoking undefined behavior anyway, so whatever happens is "right". – sbi Jun 06 '11 at 14:39
  • The error callback basically just gives some strings describing what happened, but every function that causes it will return an error code as well so I guess I will just have to handle it there. I was hoping to be able to have a generic way to handle all errors that go through that callback but allow other calls to be able to override that default behaviour by catching the exception earlier. Overall, any error that happens should be avoidable by validating input before calling functions so I will probably just go that route. Thanks for the help! – drewag Jun 06 '11 at 14:58