We have a design now, driven by:
1. compatibility with best practice exceptions in C++ (i.e. never catch by
value, etc.)
2. minimizing implementation difficulty
3. fitting in with D semantics
4. pushing as much as we can into the C++ compiler
----------------------------------------------------------
C++ exceptions cannot be thrown from D. If you must throw a C++ exception, write
and call a C++ function to do it.
C++ rethrows as well need to be done by calling a C++ function to do it.
D code can only catch C++ exceptions declared as:
extern (C++) class Identifier { ... }
Best practice in C++ is catching by const&, and D's classes fit right in with
that.
At the exit of a catch clause, the destructor on the caught C++ exception will
be run, as would be expected by C++ programmers.
Because of running the destructors, C++ exceptions cannot be caught in @safe
code.
Function bodies cannot mix catching C++ and D exceptions. (The reason is C++
catch types need to be distinguished from D catch types, and the most
straightforward method to deal with that is have a different 'personality'
function for functions that catch C++ exceptions.) However, nested functions can
catch different ones than their enclosing function.
