On Mon, Oct 6, 2014 at 7:50 AM, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
On 10/6/14, 7:01 AM, H. S. Teoh via Digitalmars-d wrote:
On Mon, Oct 06, 2014 at 06:46:31AM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
On 10/5/14, 11:39 PM, Dmitry Olshansky wrote:

It's obvious to me that one hierarchy is way to limiting for
exceptions, simply because there could be many ways to categorize the
same set of error conditions.

Well put. -- Andrei

What's the alternative, though? I can't think of any solution that
(1) isn't far more complicated than the current state of things and
(2) is easier to use.

I'm thinking a simple key-value store Variant[string] would accommodate any state needed for differentiating among exception kinds whenever that's necessary.


And 'kinds' is a synonym for 'types' - You can have different kinds of problems, so you raise them with different kinds of exceptions.

s/kind/type/g and the question is: why not leverage the type system?

For a consumer-of-something-that-throws, having different types of exceptions for different things with different data makes sense.  You have to switch on something to determine what data you can get from the exception anyway.

 
It's commonly accepted that the usability scope of OOP has gotten significantly narrower since its heydays. However, surprisingly, the larger community hasn't gotten to the point to scrutinize object-oriented error handling, which as far as I can tell has never delivered.

Maybe, but what fits better?  Errors/Exceptions have an inherent hierarchy, which maps well to a hierarchy of types.  When catching an Exception, you want to guarantee you only catch the kinds (types) of things you are looking for, and nothing else.