Le 19/02/2012 15:41, Andrei Alexandrescu a écrit :
On 2/19/12 7:31 AM, Timon Gehr wrote:
On 02/19/2012 09:26 AM, 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.
T
Nice.
That helps. This quite nicely illustrates that types don't necessarily
need to proliferate. Something not much more constraining can be done
today:
try {
...
} catch(IOException e)
{
if (e.errno !in subsetYouWantToHandle) throw e;
...
}
Andrei
This wouldn't work because you'll erase teh stack trace.
An alternative is to create a new exception and chain with e. You
discussed that in TDPL already. But It is worse than creating new types
of Exception IMO, because now, you ends up creating 2 Exceptions. And
you introduce the risk of someone silenting Exception, something that
you don't want !
