[Cfp-interest] further thoughts on exception clause syntax

[Jim Thomas]

Ugh. I’ve been busy with moving. Apologies for joining late. 

David reported input from Berkeley that the macro-based approach is too complicated, that nested macros will look especially unattractive, and that the pragma syntax isn't much better. Before taking a try-catch solution to the C committee, let’s be sure we’ve really considered the other options. Here’s another look at a pragma approach, because we already have FP pragmas in C and they don’t require language invention ...

Are pragmas too complicated? In what ways? Are the examples below too simplistic?

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 */
	}
}

(The compound statements to handle exceptions could be before the normal case.) 

Why is this particularly more complicated than the try-catch like solutions we’ve been looking at?

A reference implementation, using existing functions, for the code above could be something like

{
	#pragma STDC FENV_ACCESS ON
	fenv_t fenv;
	feholdexcept(&fenv);
	/* normal case code */
	if (fetestexcept(FE_INVALID) {
		/* handle invalid */
		feclearexcept(FE_INVALID);
	}
	if (fetestexcept(FE_OVERFLOW) {
		/* handle overflow */
		feclearexcept(FE_OVERFLOW);
	}
	feupdateenv(&fenv);
}

An ASAP version might be implemented with traps. 

Code using sub exceptions could be

{
	#pragma FE_EXCEPT FE_INVALID_DIVIDE
	/* normal case code */
	{
		#pragma FE_HANDLE FE_INVALID_DIVIDE
		/* handle invalid divide */
	}
}

It might have a reference implementation something like

{
	#pragma STDC FENV_ACCESS ON
	fenv_t fenv;
	feholdexcept(&fenv);
	/* normal case code */
	if (fetestexcept(FE_INVALID) {
		fexcept_t e;
		fegetexceptflag(&e, FE_INVALID);
		if (_Fetestsubexceptflag(&e, FE_INVALID_DIVIDE) {
			/* handle invalid divide */
		}
	}
	feupdateenv(&fenv);
}

where (in this possible implementation) the runtime maintains sticky flags for the requested sub exceptions within the relevant exception flag, and the internal function _Fetestsubexceptflag tests an except_t object for sub exceptions.

-Jim

On Jun 2, 2014, at 4:06 PM, David Hough CFP <pcfp at oakapple.net> wrote:

> 
> 
> Rajan points out that C is really intended to be a one-pass compilable
> language.    Mike points out that there's no necessity for a try block
> if you can attach exception catches to any syntactic block.    So here's
> a summary of my thinking so far; please respond with your comments:
> 
> 
> 
> try/catch constructs that differ in some details are found in C++, Java,
> Perl, PHP, Python, Matlab, and at least two Fortrans for .NET.
> Ruby has something that is somewhat different
> syntatically: there is no try keyword; catch clauses (keyword "rescue")
> can be attached to any compound statement.
> 
> Floating-point exceptions are different from
> all these other schemes, for which the presence
> or absence of catch clauses does not affect how the try clause is compiled.
> However in the case of floating-point exceptions to be detected ASAP
> by checking operands or flags, then that checking code has to be compiled
> into the try clause, just for the specific exceptions that the programmer
> has asked to be detected - one doesn't want to waste time detecting inexact
> or underflow exceptions unless the programmer asks.
>> From this point
> of view, the common syntactical convention of try followed by catch is
> a bad choice for one-pass compilers.
> 
> What could be done instead?     One could imagine having the catch_excep
> clauses before the try -
> and since they are now so syntactically different from C++ etc catch,
> we might as well leave out the "catch" and just call them "excep":
> 
> 
> 
> excep () {
> ... exception code
> }
> try {
> ... try code
> }
> 
> or perhaps
> 
> try {
> excep () {
> ... exception code
> }
> ... try code
> }
> 
> 
> And since we're deviating further from C++ syntax anyway, maybe just
> leave out the explicit try and attach to any compound statement:
> 
> excep() {
> ... exception code
> }
> {
> ... try code
> }
> 
> or
> 
> {
> excep() {
> ... exception code
> }
> ... try code
> }
> 
> To attain one-pass compilability, one could either require excep clauses to
> be before the beginning of the compound statement they modify
> or at the beginning of the compound statement that they modify.
> I don't know which would be less insulting to C.
> 
> _______________________________________________
> 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/20140603/49af5725/attachment.html