[Cfp-interest] Background: How IEEE Exceptions Might have beenImplemented

[Rajan Bhakta]

I was thinking along the same lines (though I used BASIC gosub as my 
mental example) with this or the following which merges the existing C 
methods (both flags with the functions mentioned previously, and 
exceptions, through what I can see as the only C exception handling 
facility: signals) with something similar to what you have...

void my_handler_function(int exceptionFlags) {
    // ... exception case code ...
}

{
    // … some code …
    #pragma STDC FENV_ACCESS ON
    fenv_t env; // Can be some other environment we create to keep binary 
compatibility
    fe_handle_except(&env, &my_handler_function, FE_INVALID);  // Add 
exception handler, with the exceptions that should be handled by this 
handler
    // … main case code …
    fe_unhandle_except(&env, &my_handler_function, FE_INVALID);  // Remove 
the exception handler
    feupdateenv(&env);
}

This does not allow direct substitution or continuation (which has to be 
done the same way signal handlers do it now if required), but this is the 
case with our try/catch as well. If we want that, we'd have to go back to 
the quasi-ternary operator format we initially discussed or the 
try/catch_substitute/etc.

Regards,

Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative for Canada
C Compiler Development
Contact: rbhakta at us.ibm.com, Rajan Bhakta/Houston/IBM



From:   "Mike Cowlishaw" <mfc at speleotrove.com>
To:     "'David Hough CFP'" <pcfp at oakapple.net>, 
<cfp-interest at ucbtest.org>, 
Date:   06/11/2014 10:39 AM
Subject:        Re: [Cfp-interest] Background: How IEEE Exceptions Might 
have    beenImplemented
Sent by:        cfp-interest-bounces at oakapple.net



 
> There's a familiar conflict here, like that between static and dynamic
> rounding specifications.  If the programmer for a particular function
> feels that he has correctly and explicitly
> handled all possible instances of overflow, then
> he does not want that handling overwritten by a more global 
> abort-on-overflow specification inserted for debugging purposes. 
>
> On the other hand the
> programmer of the more global function may not agree that 
> overflow has been
> correctly handled and might want a convenient way to find out where it
> occurred without recompiling source code that he doesn't have 
> access to anyway.

This particular dilemma is perhaps best left to the 'debug environment' 
(IDE,
command line, etc.) which can dictate overriding of handling at lower 
levels.
It need not be a 'language' facility or option.

Separately -- I've just caught up on the pending 50+ posts here [I have 
been
away] and one thought occurred to me: perhaps the old PL/I "On Unit" would 
fit
the bill.  As a reminder, it looks a bit like this:

   On  <exception> then <statement>

e.g., 

   On underflow then call UnderflowHandler   /* Or GoTo, longjump, local 
code,
etc. */

These would usually be placed at the start of a program (hence a nod 
towards
single-pass compile) where they also give a warning to the reader of the 
program
that exceptions are possible, while not complicating the code below. 

Related and relevant is the SIGNALS phrase in Java or NetRexx which 
indicates
that this piece of code might signal some specified exception which is NOT
handled by the code and hence MUST be handled by the caller.

Mike

_______________________________________________
Cfp-interest mailing list
Cfp-interest at oakapple.net
http://mailman.oakapple.net/mailman/listinfo/cfp-interest



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20140611/800aada8/attachment.html