The Right Approach to Exceptions

[Jonathan M Davis]

On Sunday, February 19, 2012 00:26:57 H. S. Teoh wrote:
> On Sat, Feb 18, 2012 at 11:52:00PM -0800, Jonathan M Davis wrote:
> [...]
> 
> > So, while at first glance, it seems like a good idea, I think that it
> > has too many issues as-is to work. It might be possible to adjust the
> > idea to make it workable though. Right now, it's possible to do it via
> > mixins or calling a function inside the catch, but doing something
> > similar to this would certainly be nice, assuming that we could sort
> > out the kinks.
> 
> [...]
> 
> I have an idea. What about "signature constraints" for catch, ala
> template signature constraints? Something like this:
> 
> 	try {
> 		...
> 	} catch(IOException e)
> 		if (e.errno in subsetYouWantToHandle)
> 	{
> 		...
> 	}
> 
> Just using IOException as an example. The idea is to allow arbitrary
> expressions in the constraint so whatever doesn't satisfy the constraint
> will be regarded as "not caught", even if the base type matches.

Interesting. But I don't think that it really buys you all that much, since 
normally what I'd think that you would want would simply be a list of the 
exception types that that particular catch block would handle. What you're 
suggesting would appear to end up being pretty much just ths:

try
{
    //...
}
catch(IOException e)
{
    if(e.errno in subsetYouWantToHandle)
   {
    }
    else
   {
    }
}

save for the fact that if the condition were false, in your example, you could 
presumably have a catch(Exception e) block following it which would catch it.

Honestly though, I think that something like Daniel's suggesting would be 
plenty, and it's much more explicit. Also, your suggestion might be a bit 
confusing in that it looks like a template constraint (which is evaluated at 
compile time) and yet it would have to be evaluated at runtime. That risks too 
much confusion IMHO. It's an interesting idea though.

- Jonathan M Davis