[Cfp-interest] exceptional macro

[Mike Cowlishaw]

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
>