The Right Approach to Exceptions

[Nick Sabalausky]

"Zach" <mips at intel.arm> wrote in message 
news:tpxbylbgpvarpzzlpuuf at forum.dlang.org...
> On Sunday, 19 February 2012 at 01:29:40 UTC, Nick Sabalausky wrote:
>> Another one for the file of "Crazy shit Andrei says" ;)
>>
>> From experience, I (and clearly many others here) find a sparse, flat 
>> exception hierarchy to be problematic and limiting. But even with a rich 
>> detailed exception hierarchy, those (ie, Andrei) who want to limit 
>> themselves to catching course-grained exceptions can do so, thanks to the 
>> nature of subtyping. So why are we even discussing this?
>
> How about we revisit ancient design decisions which once held true... but 
> no longer is the case due to our "god-language" being more expressive?
>

I'm fine with that when there's an alternative suggested that makes sense, 
or when there's an *actual* problem identified with the current way.

> In my experience an "exception hierarchy" is never good enough, it suffers 
> from the same problems as most frameworks also do... they simplify/destroy 
> too much info of from the original error.
>

The only problem I've ever had with them is that there's no templated catch 
blocks, so you can't handle two different exceptions with the same code 
without violating DRY or worse: catching the common base type and rethrowing 
when it's not what you wanted. Toss in templated catch blocks, and I've have 
no problem at all.

> ex why don't we throw a closure?

Haxe lets you throw literally anything. It's a useless pain in the ass 
that's along the same lines as VB being "flexible" enough to "allow" you to 
have arrays indexed from whatever random number you want. Adds no benefit, 
and just forces people to make sure to handle extra scenarios that aren't 
useful in the first place.

> Of course we could go crazy with mixins and CTFE,CTTI,RTTI aswell... imho 
> the goal should not be to do as good as java, the goal is progress! Java 
> should copy our design if anything... we could have a very rich exception 
> structure... without the need for a hierarchy.
>
> try(name) // try extended to support full closure syntax
> {
>   DIR* dir = opendir(toStringz(name));
>
>   if(dir==0 && errno==ENOTDIR)
>     throw; // throws the entire try block as a closure
> }
>

What would the use of that be?