<font size=2 face="sans-serif">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...</font>
<br>
<br><font size=2 face="sans-serif">void my_handler_function(int exceptionFlags)
{</font>
<br><font size=2 face="sans-serif"> // ... exception case
code ...</font>
<br><font size=2 face="sans-serif">}</font>
<br>
<br><font size=3>{</font>
<br><font size=3> // … some code …</font>
<br><font size=3> #pragma STDC FENV_ACCESS ON</font>
<br><font size=3> fenv_t env; // Can be some other environment
we create to keep binary compatibility</font>
<br><font size=3> fe_handle_except(&env, &my_handler_function,
FE_INVALID); // Add exception handler, with the exceptions that should
be handled by this handler</font>
<br><font size=3> // … main case code …</font>
<br><font size=3> fe_unhandle_except(&env, &my_handler_function,
FE_INVALID); // Remove the exception handler</font>
<br><font size=3> feupdateenv(&env);</font>
<br><font size=3>}</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">Regards,<br>
<br>
Rajan Bhakta<br>
z/OS XL C/C++ Compiler Technical Architect<br>
ISO C Standards Representative for Canada<br>
C Compiler Development<br>
Contact: rbhakta@us.ibm.com, Rajan Bhakta/Houston/IBM</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Mike Cowlishaw"
<mfc@speleotrove.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"'David Hough
CFP'" <pcfp@oakapple.net>, <cfp-interest@ucbtest.org>,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">06/11/2014 10:39 AM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [Cfp-interest]
Background: How IEEE Exceptions Might have beenImplemented</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">cfp-interest-bounces@oakapple.net</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2> <br>
> There's a familiar conflict here, like that between static and dynamic<br>
> rounding specifications. If the programmer for a particular
function<br>
> feels that he has correctly and explicitly<br>
> handled all possible instances of overflow, then<br>
> he does not want that handling overwritten by a more global <br>
> abort-on-overflow specification inserted for debugging purposes.
<br>
><br>
> On the other hand the<br>
> programmer of the more global function may not agree that <br>
> overflow has been<br>
> correctly handled and might want a convenient way to find out where
it<br>
> occurred without recompiling source code that he doesn't have <br>
> access to anyway.<br>
<br>
This particular dilemma is perhaps best left to the 'debug environment'
(IDE,<br>
command line, etc.) which can dictate overriding of handling at lower levels.<br>
It need not be a 'language' facility or option.<br>
<br>
Separately -- I've just caught up on the pending 50+ posts here [I have
been<br>
away] and one thought occurred to me: perhaps the old PL/I "On Unit"
would fit<br>
the bill. As a reminder, it looks a bit like this:<br>
<br>
On <exception> then <statement><br>
<br>
e.g., <br>
<br>
On underflow then call UnderflowHandler /* Or GoTo, longjump,
local code,<br>
etc. */<br>
<br>
These would usually be placed at the start of a program (hence a nod towards<br>
single-pass compile) where they also give a warning to the reader of the
program<br>
that exceptions are possible, while not complicating the code below. <br>
<br>
Related and relevant is the SIGNALS phrase in Java or NetRexx which indicates<br>
that this piece of code might signal some specified exception which is
NOT<br>
handled by the code and hence MUST be handled by the caller.<br>
<br>
Mike<br>
<br>
_______________________________________________<br>
Cfp-interest mailing list<br>
Cfp-interest@oakapple.net<br>
</font></tt><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest"><tt><font size=2>http://mailman.oakapple.net/mailman/listinfo/cfp-interest</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br>