Exceptions and throwing across module boundaries

One of the problems with exceptions that we've run into recently is throwing across module boundaries -- we hit a case where an exception thrown in one module cannot be caught as anything but a std::exception in a module compiled with different settings (same compiler -- gcc 4.2). This is of course item #62 in "C++ Coding Standards". Since we'd prefer to use exceptions rather than return codes as our error reporting mechanism, I'm currently investigating possible solutions to this. I was hoping to find something applicable boost, but it looks like boost doesn't differentiate between throwing in a header vs. throwing in a module -- for example, Boost.Thread has a few throw statements in cpp files (both in posix and win32). Is this just an issue that hasn't been enough of a problem to address? The approach I am considering is wrapping module interfaces with a translation layer which turns an exception to an error code, which is re-translated back to an exception in the header used by client code. Has anyone done anything similar? Is there something in boost like this already? (I was hoping to find something in Boost.Exception, but it does not appear to solve this situation). Thanks Josh

On Wed, Nov 11, 2009 at 2:08 PM, Josh Faust
we hit a case where an exception thrown in one module cannot be caught as anything but a std::exception in a module compiled with different settings (same compiler -- gcc 4.2).
The fact that catch(std::exception&) works for you is a coincidence.
Since we'd prefer to use exceptions rather than return codes as our error reporting mechanism, I'm currently investigating possible solutions to this. I was hoping to find something applicable boost, but it looks like boost doesn't differentiate between throwing in a header vs. throwing in a module -- for example, Boost.Thread has a few throw statements in cpp files Is this just an issue that hasn't been enough of a problem to address?
In general, a library might not work at all if its CPP files are compiled with different settings than the user code, even if it didn't throw any exceptions, because C and C++ do not define an ABI. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On Wed, Nov 11, 2009 at 4:06 PM, Emil Dotchevski
On Wed, Nov 11, 2009 at 2:08 PM, Josh Faust
wrote: we hit a case where an exception thrown in one module cannot be caught as anything but a std::exception in a module compiled with different settings (same compiler -- gcc 4.2).
The fact that catch(std::exception&) works for you is a coincidence.
Yeah, that was just an example.
Since we'd prefer to use exceptions rather than return codes as our error reporting mechanism, I'm currently investigating possible solutions to this. I was hoping to find something applicable boost, but it looks like boost doesn't differentiate between throwing in a header vs. throwing in a module -- for example, Boost.Thread has a few throw statements in cpp files Is this just an issue that hasn't been enough of a problem to address?
In general, a library might not work at all if its CPP files are compiled with different settings than the user code, even if it didn't throw any exceptions, because C and C++ do not define an ABI.
I suppose my impression was that exceptions are an even worse case -- but now that I think about it we've run into other compiler setting ABI issues before as well. Maybe this is a non-issue because we're not trying to provide a perfectly clean interface (char* and other builtins only). Thanks Josh
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

On Wed, Nov 11, 2009 at 4:50 PM, Josh Faust
I suppose my impression was that exceptions are an even worse case -- but now that I think about it we've run into other compiler setting ABI issues before as well. Maybe this is a non-issue because we're not trying to provide a perfectly clean interface (char* and other builtins only).
Right, an old-school C interface defined in terms of built-in types and pointers to incomplete types is the way to go if a stable ABI is important, though there is some value in also allowing things like shared_ptr and function to pass through the interface barrier because they are more resistant to breaking due to ABI incompatibilities compared to "general" code. As far as I'm concerned, if a C++ interface uses anything more than that, then building everything from source using compatible compiler settings is required. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
participants (2)
-
Emil Dotchevski
-
Josh Faust