[Cfp-interest] exceptional macro

[Jim Thomas]

I don’t see that testing/handling some exceptions in a block reduces the need to have other exceptions from that block reported. To avoid losing the information that an exception occurred, the programmer would have to test and handle all possible exceptions. I think the point that other exceptions might be added in the future is another argument in favor of default exception handling (or exception handling from an outer block) for the exceptions not explicitly listed.

On May 14, 2014, at 7:35 AM, Mike Cowlishaw <mfc at speleotrove.com> wrote:

> 
>> Part of the semantics of FP_EXCEPTIONAL is that it preserves 
>> the previous state of the flags and traps for exceptions that 
>> are mentioned, since these were anticipated, but not flags 
>> and traps for exceptions that were not mentioned, since these
>> were not.    
> 
> I'm a little uncomfortable with that because there may be new exceptions added
> in the future (or implementation-specific, such as the 'Clamped' flag in
> decNumber).  Having to specify all 'expected' exceptions could be difficult.
> 
>> What semantics would you propose for FP_EXCEPTIONS ?
> 
> My initial/gut feeling would be to preserve/restore all.  i.e., state after the
> call is identical to that before the call.  That way the call is simply a test,
> with no side-effects.
> 
> Mike
> 
> 
> ----- 
>>>> FE_EXCEPTIONAL( expression or compound statement, 
>>>>                 exception1, exception2, ...)
>>> 
>>> Rather than having the multiple arguments, perhaps it could 
>>> be simply
>>> 
>>>  FE_EXCEPTIONS( expression )
>>> 
>>> which returns the exceptions raised in the evaluation of the 
>>> expression (or compound statement if that's allowed), ORed 
>>> together.  
>>> (Assuming the exceptions & subexpressions are defined to be 
>>> bit-unique.)
> 
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest