[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Status Returns
- To: "Rees@YALE-CS" at YALE
- Subject: Re: Status Returns
- From: John R. Ellis <Ellis at YALE>
- Date: Wed ,24 Jun 82 15:10:00 EDT
- Cc: Baldwin at YALE, T-Discussion at YALE
- In-reply-to: Rees's message of Thursday, 24 June 1982 14:39-EDT
The Mesa people have had the most experience with handling "exceptional
conditions"; I would recommend that someone dig up their most recent papers
(maybe Alan or Mike Fischer can get them) to see what they have to say
about "normal conditions" versus "exceptional conditions".
There are good arguments for both styles (returning a unique value versus
raising an exception). The constructs Kent implemented/proposed last
summer are very similar in style to Mesa constructs. The two important
arguments against using exception handling in "normal situations" (reading
end of file is a "normal situation", as is often not finding a file):
1. In large systems, it is very hard to avoid the physical and logical
separation of handlers and the code that could potentially raise
conditions. Kent's stuff, like Mesa, does not solve this.
2. Without exceptions, the programmer is forced to deal with the
possibility of "failure" explicitly, immediately. Xerox's
experience is that in the long run this produces much cleaner,
better structured systems. The tendency with large systems built
on exceptions is to delay providing clean and robust handlers
until very late in the development, by which time it is too late
to do it correctly. Of course you could do the development
"right", but in practice this doesn't happen. This is an important
sociological point about programming with exceptions.
As I understand it, the general feeling at Xerox now is to use exceptions
only for those things that should never happen "normally" (disk failure).
Opening a file can fail "normally" and should not be handled with
I don't fully agree with these arguments, but they should
be taken seriously.