I don't understand: std::exception is entirely optional (and I, for example, never use it: I always build my own exception hierarchy; but, even though I write my native code almost exclusively in C++, I believe it is absolutely incorrect to expose a C++ API from a library, so you'd never know or care) while in Java you absolutely have to implement Throwable and Exception is actually designed well enough that most people (not me, of course ;P) generally use it... I mean, in C++ you literally can just throw a "const char *" and catch that.
I will say that I didn't provide an argument for not using std::exception, nor was I trying to convince someone else not to do so; I was simply stating that C++ does not require it and a lot of code doesn't use it: it sounded like the person I was responding to was claiming that in C++ you knew everything was eventually std::exception while that wasn't the case for Java, when the exact opposite is actually true (that in C++ you can and often do run into cases where an exception is just some random data type, and in Java all exceptions fundamentally must implement Throwable as an engine constraint). I only used the fact that I don't use it as an example of someone who doesn't. FWIW, I actually use a lot of my code in environments where I can't use the standard library, so even your paragraph of why you supposedly believe the opposite of some ancillary point I wasn't trying to make you have admitted why I do what I do is valid even to you.
> I sympathize with C-compatible API's to simplify an interface, though it's not my first choice.
It isn't about simplifying an interface: it is because in addition to the C++ ABI being itself fundamentally brittle (due to vtable ordering), you have to remember that some people use libstdc++ while others are now annoyingly using libc++ (I blame Apple, and I have absolutely no sympathy: they have ruined what little interoperability we used to have in this ecosystem they cared absolutely nothing for), and the ABIs between popular compilers is different; so when someone uses a C++ interface for their library I spend the next three days cursing their name and adding them to my "never let this person program anything ever again" list while I waste my time pulling crazy stunts to dynamically look up mangled symbol names and working around egregious incompatibilities in basic things like "when a C++ member function returns a structure, MinGW puts the hidden structure return pointer first while MSVC puts it after the hidden this pointer".
At this point I know the ABI of every major compiler on every major architecture, and I have been considering switching entirely to gcc and contributing a ton of patches that let me #pragma mark entire regions of code (due to header files) with specific calling conventions and layout ABIs, as this attitude that C++ is somehow appropriate for this purpose is creeping into more and more places as C++11 has caused more and more people to start using C++ without understanding its limits :/.
The important thing with exceptions in C++ is having a root class. I use std::exceptions, others are also ok as long as they are used consistently. If the goal is to trap everything, like in a library even ... is ok.
The big difficulty lies in isolating certain kinds of exceptions to components. Some are recoverable, others should lead to termination, some should interrupt the current operation, others should trigger a retry. The type system offers no support with that.
Verification of noexcept would be a start, as it allows some rudimentary marking of boundaries.
Object layouts will be likely different and the main program will probably crash.
The breakage from mixing different library versions (say, MSVCRT versions, for example) is a direct result of violating the ODR.
Make sure that your compiler provides a stable std library ABI.
Is this done a lot in practice? I had the impression that a lot of projects stick to C APIs in dynamic libraries.
In practice the reason that many projects provide a C ABI is that they want to interoperate with other languages and the C ABI, being extremely minimalist, is the least common denominator.
I don't care what gets thrown, because it's in the end going to be an std::exception (this is the part that Java messed up)
I do care if a function will throw, because it radically changes its behavior.
The problem I want to avoid is a silly function such as stoi throwing and having the exception propagated up to main, after which the whole program (orderly) shuts down. Right now this can be avoided only with careful exception design and making sure all exception "escape points" to C functions, message loops, etc are covered.
Swift I think is one of the few languages supporting this.