Program logic bugs vs input/environmental errors (checked exceptions)

[Jeremy Powers via Digitalmars-d]

On Mon, Oct 6, 2014 at 6:19 PM, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141007/a2664260/attachment.html>