Can we make Throwable an interface?

[Lars T. Kyllingstad via Digitalmars-d]

On Tuesday, 9 December 2014 at 17:06:45 UTC, Dmitry Olshansky 
wrote:
> Then we could use interfaces as "tags" for exceptions and catch 
> using one of many interfaces an exception has.

I think that is an excellent idea!  I have looked a bit at 
boost::exception, and wanted for a while to incorporate something 
similar into DIP33.  It has two important features:

Firstly, it allows semantic tagging of exceptions, which is 
implemented in C++ by means of multiple (virtual) inheritance.  
Your suggestion of using interfaces for this would fit the bill 
nicely, I think.  For interfaces that have extra functions, we 
could supply standard implementations of those functions as mixin 
templates for when users don't want to implement those functions 
themselves.

Secondly, boost::exception allows for transport of arbitrary data 
to the catch site, and importantly, supplying additional data as 
the exception propagates up the call chain.  (E.g., the 
lowest-level I/O function only has a file descriptor and can only 
provide an errno code, so the file name must be supplied at a 
higher level, e.g. in std.stdio.File.  Furthermore, the file was 
opened in some context, e.g. "read image file", which may also be 
useful to know at the catch site.)  I'm not sure what is the best 
way to achieve this in D, but one option is to use an 
(associative?) array of Variants.


> Consider DIP33:
> http://wiki.dlang.org/DIP33
>
> The 2 problems it had were:
>
> 1. enums are hard to extend for std lib, and absolutely 
> impossible by 3rd party libraries.
> 2. Single hierarchy has some appeal but it doesn't allow to 
> catch on similar classes that do not inherit from the same base 
> class. Basically there are many ways to view similarities of 
> excpetions and single hierarchy fails to address that.

I consider (2) the biggest problem by far.  The enum solution 
doesn't preclude extension by subclassing – in fact, that was the 
main purpose of the "unknown" constant in the "Kind" enums.

Lars