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

Jeremy Powers via Digitalmars-d digitalmars-d at puremagic.com
Mon Oct 6 16:46:41 PDT 2014


On Mon, Oct 6, 2014 at 7:50 AM, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On 10/6/14, 7:01 AM, H. S. Teoh via Digitalmars-d wrote:
>
>> On Mon, Oct 06, 2014 at 06:46:31AM -0700, Andrei Alexandrescu via
>> Digitalmars-d wrote:
>>
>>> On 10/5/14, 11:39 PM, Dmitry Olshansky wrote:
>>>
>>>>
>>>> It's obvious to me that one hierarchy is way to limiting for
>>>> exceptions, simply because there could be many ways to categorize the
>>>> same set of error conditions.
>>>>
>>>
>>> Well put. -- Andrei
>>>
>>
>> What's the alternative, though? I can't think of any solution that
>> (1) isn't far more complicated than the current state of things and
>> (2) is easier to use.
>>
>
> 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?

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.



> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141006/c1e4fef3/attachment.html>


More information about the Digitalmars-d mailing list