DE wrote:
on 01.04.2010 at 23:59 Scott McMurray wrote :
The worry I have is with compound expressions. It looks nice for a single function call, but compare these two lines:
w = x/y*z; w = x*y/z;
With a signalling NaN, their exceptional behaviour is drastically different.
This is another example of the advantage of the split types: If x, y, and z are nothrow_xints, the type of w is what decides whether the statement will throw. Alternatively, if x, y, and z are finite_xints, both statements will throw and never touch w.
they are throwing anyway whether or not exceptions are blocked blocking of exceptions allows you to check explicitly if a number of operations like division succeeds
I was under the impression that "w = x*y/z" wouldn't throw under the current NaN behavior... [...]
but blindly writing such expressions is irrelevant to the nan behaviour because both eventually throw
It is certainly relevant since varying when a certain sequence of operations throws alters the state of the program at the catch site! This is why I prefer "throw as early as possible", since you're not overwriting your variables (e.g., w) with NaNs, hence you have more information available to you. And if you don't want to throw as early as possible (e.g., because exceptions are blocked, or that's what the policy parameter dictates), then don't throw at all.
we are spinning and spinning around the same thing for a week is there an end?
How the library handles exceptions (or doesn't) is an important part of the interface. - Jeff