Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!decwrl!wuarchive!mit-eddie!uw-beaver!ubc-cs!news-server.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!davecb
From: davecb@yunexus.YorkU.CA (David Collier-Brown)
Newsgroups: comp.lang.eiffel
Subject: Re: Exceptions and Assertions
Keywords: eiffel exceptions assertions preconditions
Message-ID: <14831@yunexus.YorkU.CA>
Date: 7 Sep 90 13:08:13 GMT
References: <1990Sep7.032121.6456@bony1.uucp>
Organization: York U. Computing Services
Lines: 50

Speaking of exceptions, Rick Jones writes:
| One of Eiffel's most powerful features is its exception handling, and in my
| current work I am experimenting with a programming style which places heavy
| reliance on this system.  The general concept is that _all_ "non-normal"
| conditions are treated as exceptions, including those which may be expected to
| occur quite frequently.

richieb@bony1.uucp (Richard Bielak) writes:
| IMHO, pushing non-normal cases into exception handlers is wrong. An
| exception should only be used to handle the cases that were not
| foreseen by the developer. Doing a "raise" and handling a condition
| elsewhere in the program has two problems:

| 1) Flow of the code is hidden from the programmer reading the code; a
| "raise" is almost as bad as a GOTO.

| 2) If too much code is put in an exception handler, what will happen
| if the handler encounters an exception? 

  We're really seeing a continuum here: the normal case, the general case
and the exceptional case.

  In the normal or common case, one wants to pass through a concise,
understandable sequence of code.  Often one wants this to be fast, in
some sense of the word.
  In the general case, one has to deal with the boundary conditions,
special oddities, etc, or the algorithm. Donald Knuth and PL/1 programmers
like this code to be physically but not logically separate.  Smalltalk
programmers like this to be both physically and logically separate and
"fault" into it.  Most other programmers write it as part of the common
case, often making it hard to understand.
  In the exceptional case, on has to deal with "can't happen" events.
Programmers with languages supporting exceptions make these exceptions,
and have them physically and logically separate.  People who don't have
exceptions fold them in with the general case...

   Exception-handlers are suitable for exceptions, but probably not
for the general-case, predictable boundary/oddball conditions. We
need a notation for the latter...
   As a palliative, I either use web and put them on a separate page, or
write little parameterless procedures that tag along with the parent
procedure.  The latter is an explicit kludge.


--dave
-- 
David Collier-Brown,  | davecb@Nexus.YorkU.CA, ...!yunexus!davecb or
72 Abitibi Ave.,      | {toronto area...}lethe!dave or just
Willowdale, Ontario,  | postmaster@{nexus.}yorku.ca
CANADA. 416-223-8968  | work phone (416) 736-5257 x 22075