The Right Approach to Exceptions

[Alf P. Steinbach]

On 19.02.2012 02:17, H. S. Teoh wrote:
>
> The basic problem with C++ exceptions is that it allows you to throw
> literally *anything*. Which is nice and generous, but not having a
> common root to all exceptions cripples the system, because there is no
> functionality that can be depended upon, like toString when what you
> want is an error message.

No, that is a misunderstanding (completely).

However, C++ exceptions do have many problems, including:

   * Until C++11, no support for propagating exceptions through
     non-exception-aware code (in particular, from C callbacks).

   * No support for wchar_t exception text, i.e. *nix-specific.

   * A nonsensical exception class hierarchy with e.g.
     std::logic_error and std::bad_exception.

   * No differentiation between recoverable (soft, failure) and
     unrecoverable (hard, error) exceptions, although some people have
     argued that in the latter case one is screwed anyway.

   * Involving std::string arguments, so that in low memory
     conditions throwing an exception can itself throw.

Especially the last point is pretty silly. :-)

And then when C++11 added support for propagating error codes, it was 
designed as *nix-specific (char-based messages only) and overly complex.

I haven't heard about anyone actually using that stuff.


> Furthermore, not having a properly designed skeletal hierarchy to
> inherit from also adds to the problem. With no existing standard
> hierarchy to serve as a reference point, library writers just invent
> their own systems, most of which don't interoperate properly with each
> other. And thus the mess that is the C++ exception hierarchy.
>
> I certainly hope D can do better than that.

Agreed.


Cheers,

- Alf