Passing exceptions through DLL/SO boundaries

Question

I am trying to find compiler features which will work if shared library compiled using standard library that differ from standard library of executable, that load shared lib. I understand that ABI of standard library is standardized nowhere, but I can use my own base class for all exceptions.

I found that exception handling ABI standardized on Linux (Itanium C++ ABI: Exception Handling), and on Windows (x64 exception handling).

Also as I understand data alignment standardized too (System V Application Binary Interface AMD64 Architecture Processor Supplement, x64 software conventions).

• Target architectures: amd64, AArch64;
• Target platforms: Linux, Windows.

Can I use exceptions or I need to handle them at the DLL/SO boundaries?

Can I use exceptions if executable and shared library use different compilers (MSVC and GCC or GCC and MSVC respectively)

Answer 1

It is not necessarily even safe to use exceptions across boundaries of modules compiled with different versions of the same tool-set.

For example, your exception type may have a std::string member but std::string can be implemented very differently from one standard library version to another. If your library module were compiled with an old tool-set but the client program with a newer version the exception would be populated with objects that match the old implementation but the program would then try accessing it as if it were the new implementation.

Honestly, this is true for pretty much all C++ non-POD types, not just exceptions. It is possible to use C++ objects across library boundaries but generally only so long as all of the code is compiled and linked using the same tools and standard libraries. This is why, for example, there are boost binaries for all of the major versions of MSVC.

I suppose you might be able to get away with throwing a POD exception type that is not derived from std::exception but that would be very limited (for example it would require catching the exact type).