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
