Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!ihnp4!ihlpf!nevin1
From: nevin1@ihlpf.ATT.COM (00704a-Liber)
Newsgroups: comp.lang.c++
Subject: Re: Proposal for Exceptions for C++
Message-ID: <4194@ihlpf.ATT.COM>
Date: 30 Mar 88 01:21:06 GMT
References: <8180006@eecs.nwu.edu>
Reply-To: nevin1@ihlpf.UUCP (00704a-Liber,N.J.)
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 133

First off, this is not meant as a flame against Vance.  It takes a lot of
effort to come up with a proposal, and it is appreciated.  But, Vance, you
asked for criticism and now you are going to get it! :-)


In article <8180006@eecs.nwu.edu> morrison@eecs.nwu.edu (Vance Morrison) writes:
.A PROPOSAL FOR ADDING EXCEPTION HANDLING TO C++
.
.	Only three changes to the syntax of the language are necessary
.
.	1) Add the statement '_raise' to the language:
.	1) Add the statement 'resume' to the language:
.	2) Any statement can now be followed by the following construct
.		catch <statement>
.	   For example
.		i = j/k; catch { printf("divide by zero error\n"); }
.	  
.	As one might expect, '_raise' raises an exception, while 'catch'
.declares a handler for a statement.  Thus whatever statement precedes
.'catch' is "protected", in the sense that if any exception is raised
.in the protected statement, control is given to the statement after
.'catch'.
...
.	After the statement after 'catch' is executed, _raise IS 
.IMPLICITLY CALLED.
...
.	This behavior is deliberate.  The reasoning is that error 
.conditions should NEVER be ignored by default.

Yes, but since you are already define a 'catch' routine you are obviously
not ignoring the error condition.  For this reason, I feel that the resume
should be implicit and the _raise be explicit (BTW, if you _raise from a
catch routine you should go to the next catch routine if there is one
defined for the first catch routine).  This is a minor point, though.


.SYNTACTIC AMBIGUITIES
.
.In the following example
.
.	for(i=0; i< 10; i++) {
.	    printf("%d\n", err());
.	    } catch {
.		printf("error\n");
.		resume;
.		}
.	    
.	Is the 'catch' statement only protecting the printf, or
.the whole for(;;) statement?  Here we define it to be just the
.printf statement.

This seems to be inconsistent, since if you really wanted to protect only
the printf("%d...), you could declare the catch just after it.  You example
should just catch if 'for' raises an exception (if the printf("%d...) has
an error, no catch routine is called).  If you want both the for statement
and the printf("%d...) to be caught, putbrackets around the for statement
and put the catch after the closing bracket (such as the way you do it for
function bodies--see below).

.FUNCTION BODIES

.A function body is a legal statement to catch thus
.
.	int main()
.	{
.	    err();
.
.	    return(0);
.	} catch {
.	    printf("err\n");
.	    return(-1);
.	    }
.
.	Is legal and protects the whole function body.  Note
.that 'return' is a legal statement in a catch clause, and is
.another way to escape from a catch clause (goto will also work).  
...
.****** PROGRAM USING MODULE ****************************************
.#include <stdio.h>
.#include "exception.h"
.#include "example.h"
.
.main()
.{
.	/* call file_call and catch the FILE_ERROR FILE_NUMBERS */
.
.    file_call(); catch {
.	if (FILE_ERROR.is_raised()) {
.	    printf("caught file error\n");
.	    resume;	
.	    }
.	if (FILE_NUMBERS.is_raised()) {
.	    printf("caught file number error with param %d\n", 
.		FILE_NUMBERS.number());
.	    resume;	
.	    }
.	}
.
.    printf("done\n");
.}

Unfortunately, this does not look all that much different from (using your
file_call() function call as an example):

	if (BAD_VALUE == file_call())
	{
		do some error processing
	}

so I don't see that I am gaining all that much (although this may only be
due to a poor choice of examples).


The power of exceptions comes from being able to move error handling code
away from the actual function calls.  But, if this is to be done in the
'spirit of C++', it must:

a)	Be able to be translated into C

b)	Not incur much (or any, if possible) run-time overhead for code
	which doesn't use exception handlers

c)	Do something which cannot now be done in C++ or do something
	significantly better than it is already done in C++

and I don't think that your method can meet all these goals.  I think that
if you also proposed a method of implementation, we would be able to give
you many more detailed, relevant comments.
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				"The secret compartment of my ring I fill
 /  / _ , __o  ____		 with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah