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?