[Cfp-interest] further thoughts on exception clause syntax

[Jim Thomas]

On Jun 3, 2014, at 5:37 PM, David Hough CFP <pcfp at oakapple.net> wrote:

> 
>> A solution with pragmas (2 of them) would allow code like
>> {
>> #pragma FE_EXCEPT FE_OVERFLOW, FE_INVALID
>> /* normal case code */
>> {
>> #pragma FE_HANDLE FE_OVERFLOW
>> /* handle overflow */
>> }
>> {
>> #pragma FE_HANDLE FE_INVALID
>> /* handle invalid */
>> }
>> }
> 
> I'll let the C experts chime in, but I don't see how this is any simpler
> for the compiler than
> 
> try {
> #pragma FE_EXCEPT FE_OVERFLOW, FE_INVALID
> /* normal case code */
> catch_FE_HANDLE (FE_OVERFLOW) {
> /* handle overflow */
> }
> catch_FE_HANDLE (FE_INVALID) {
> /* handle invalid */
> }
> }

I’m worried about it as an issue for the language specification, not compilers.
> 
> Remember we're just talking about using the C++ try/catch syntax, not
> duplicating all its semantics.     As Mike pointed out, we don't really
> need the "try":
> 
> {
> #pragma FE_EXCEPT FE_OVERFLOW, FE_INVALID
> /* normal case code */
> catch_FE_HANDLE (FE_OVERFLOW) {
> /* handle overflow */
> }
> catch_FE_HANDLE (FE_INVALID) {
> /* handle invalid */
> }
> }
> 
> and as Rajan pointed out, this form is problematic for a one-pass compiler,

Hmm. Seems like the pragma at the beginning (telling the compiler which exceptions have to be watched) should be sufficient.

> so indeed
> 
>> (The compound statements to handle exceptions could be before the normal case.)
> 
> thus:
> 
> {
> catch_FE_HANDLE (FE_OVERFLOW) {
> /* handle overflow */
> }
> catch_FE_HANDLE (FE_INVALID) {
> /* handle invalid */
> }
> /* normal case code */
> }
> 
> or translating back to pragmas:
> 
> {
> {
> #pragma FE_HANDLE FE_OVERFLOW
> /* handle overflow */
> }
> {
> #pragma FE_HANDLE FE_INVALID
> /* handle invalid */
> }
> /* normal case code */
> }
> 
> In any case, the compiler has to recognize a handler when it sees it,
> and set up that handler for the appropriate explicit or implicit try block.
> 
> The preferred implementation for loops at least is by trapping so the
> normal case is not slowed.    Jim's reference implementation would work
> but testing after the loop might mean slow performance (in the case of
> lots of underflows)

Right. It’s just a reference implementation.

> or infinite loops, if NaNs propagate into comparisons
> so an exit condition is never satisfied.

Yes, using traps would make for a better implementation, for multiple reasons.
>