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

Jeremy Powers via Digitalmars-d digitalmars-d at puremagic.com
Tue Oct 7 14:33:26 PDT 2014


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.


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


More information about the Digitalmars-d mailing list