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. > > 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. > > I'm not talking theory (exclusively). From a practical standpoint, if I ever need information from an exception I need to know what information I can get. If different exceptions have different information, how do I tell what I can get? Types fits this as well as/better than anything I can think of. > 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). > > Most/virtually all of the time I am looking only for the kind of exceptions I expect and can handle. If I catch an exception that I was not expecting, this is a program bug (and may result in undefined behavior, memory corruption, etc). Catching all is almost _never_ what I want. I have not found a whole lot of use for deep exception hierarchies, but some organization of types/kinds of exceptions is needed. At the very least you need to know if it is the kind of exception you know how to handle - and without a hierarchy, you need to know every single specific kind of exception anything you call throws. Which is not tenable.