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).
Andrei
