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