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