On Mon, Oct 6, 2014 at 6:19 PM, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
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.

Sorry, forgot to respond to this part.

As mentioned, I'm not a defender of hierarchies per se - but I've not seen any alternate way to accomplish what they give.  I need to know that I am catching exceptions that I can handle, and not catching exceptions I can't/won't handle.  Different components and layers of code have different ideas of what can and should be handled.

Without particular exception types, how can I know that I am only catching what is appropriate, and not catching and swallowing other problems?