[Cfp-interest] more on try/catch

David Hough CFP pcfp at oakapple.net
Fri May 30 07:50:11 PDT 2014


> try/catch style due to the opinion 
> it would be a hard sell to the C committee (and likely C compiler vendors 
> as well).
> Have we decided to change that approach or are we still just making 
> proposals in case the #pragma or macro magic does not work?

At this point I am just looking for the most intuitive syntax that
support nesting tolerably and debuggably.      
Both #pragma and magic macros leave a lot to be desired in that department.

It's just as much work for the compiler/system no matter what.    
Implementers won't like it any more just because the syntax is not
natural to C++ either.
The try block, whatever it is called, has to be compiled 
taking into account which 
exceptions are to be tested.     That is why the floating-point catch
clauses should probably have a different keyword than "catch" to avoid
confusion on that point.

C++ and Java have very similar try/catch; Python does too except it says
"except" rather than "catch."    
So that seems to be the way the world is going and what programmers might
expect.
Standard Fortran doesn't help much,
but googling, I found that Lahey Fortran for .NET has a try/catch extension.

> The rule could be that the floating-point exceptions to be checked for
> would be those which have a catch clause naming them, but that's not true
> for general C++ exceptions so would be an inconsistency.  
> A portable way to
> specify which ones to enable would be useful; for example it could be 
> a function like

>        FPEnable  oldcontrols =3D enableFPExceptions (FPEnable::Overflow |
>	FPEnable::InvalidOperation | FPEnable::ZeroDivide);

> which sets up exception checking controls and returns the old exception
> controls, along with another function to restore the saved controls
> afterwards.

Having to specify the same information twice seems error prone.
One of the goals here is to specify the desired behavior as succinctly
as possible at a level meaningful to the application,
rather than specifying the implementation.


More information about the Cfp-interest mailing list