[Cfp-interest] exceptional macro

[Jim Thomas]

Are you really meaning this just to be a test function/macro, like sizeof? If an expression argument is (p = x * y), is the object p modified? I was assuming it was. In which case, it’s not just a test function. That is, it’s not just the query: would the evaluation of this expression or execution of this compound sentence produce these exceptions? The expression (compound statement) is actually evaluated (executed) (at least in the usual case that one of the listed exceptions does not occur) as part of the computation of numerical results. The only thing different about this part of the computation is that some of the exceptions (maybe just one sub exception) are handled. Why is it not important to report the unhandled exceptions? How does reporting these unhanded exceptions compound the problem (any more than reporting any other exceptions)?

-Jim

On May 19, 2014, at 11:25 AM, Mike Cowlishaw <mfc at speleotrove.com> wrote:

> 
> I agree.  Programmers in general -- in contrast to those writing specialist or
> fundamental libraries -- are really only concerned about whether any exceptions
> that occurred are 'serious' (cast doubt on the result and suggest rework or
> analysis) or are 'informational' (working as normal but an exact result has not
> been delivered, for example).
> 
> Whatever the motivation for reporting results, A "test" function (or macro)
> should not have side effects, because if it does it compounds a problem rather
> than being a means to a solution.
> 
> Mike
> 
> 
> 
>> -----Original Message-----
>> From: Jim Thomas [mailto:jaswthomas at sbcglobal.net] 
>> Sent: 19 May 2014 19:12
>> To: Mike Cowlishaw
>> Cc: CFP
>> Subject: Re: [Cfp-interest] exceptional macro
>> 
>> 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
>> 
>