On 10/6/14, 4:46 PM, Jeremy Powers via Digitalmars-d wrote:

On Mon, Oct 6, 2014 at 7:50 AM, Andrei Alexandrescu via Digitalmars-d
    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?

I've used "kinds" intentionally there. My basic thesis here is I haven't seen any systematic and successful use of exception hierarchies in 20 years. In rare scattered cases I've seen a couple of multiple "catch"es, and even those could have been helped by the use of a more flat handling. You'd think in 20 years some good systematic use of the feature would come forward. It's probably time to put exception hierarchies in the "emperor's clothes" bin.

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.

Oh yah I know the theory. It's beautiful.

    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.

Yah, it's just that most/virtually all of the time I'm looking for all. And nothing else :o).