From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,f66d11aeda114c52
X-Google-Attributes: gid103376,public
X-Google-Thread: fac41,f66d11aeda114c52
X-Google-Attributes: gidfac41,public
From: Joachim Durchholz <joachim.durchholz@munich.netsurf.de>
Subject: Re: Building blocks (Was: Design By Contract)
Date: 1997/09/15
Message-ID: <341DA755.CA55073C@munich.netsurf.de>#1/1
X-Deja-AN: 273034248
References: <5v34m5$pl9$1@trumpet.uni-mannheim.de>
X-Priority: 3 (Normal)
Newsgroups: comp.lang.ada,comp.lang.eiffel
Date: 1997-09-15T00:00:00+00:00
List-Id: <comp.lang.ada>


Marc Wachowitz wrote:
> ...I consider something like Eiffel's class EXCEPTION an ugly
> hack to differentiate between kinds of exceptions.

Indeed it is. Mimicking Java's elaborate I/O exception hierarchy would
be a nightmare.

However, exceptions don't have to serve as many purposes in Eiffel as in
Java.

First of all, Eiffel is designed for side-effect-free functions. A
subroutine is either a command (procedure, function with void return
type) that may change the externally perceivable state of an object. Or
it is a query (function, function with non-void return type) that allows
us to perceive the state of the object.
This means file I/O (to most plentiful source of exceptions I think)
works totally different than in Java or C. There is no getchar()
function, which would change the state of the associated FILE object
*and* return a value. Instead, you can have a get_file_block(from,to)
procedure that tries to read the bytes in the given from..to range; if
an I/O error occurs, the FILE object takes note of the error. Nothing
else is done in get_file_block; however, FILE also offers a set of
queries to determine wether the last access was successful, failure
reasons if not, access to data as far as it could be read, etc. etc.

What remains for exception handling are two sources:
1) Truly unexpected stuff, which is traditionally reported with the
prefix "This can't happen:". There isn't much that can be done about
such events - a human must look at the message and decide what to do -
which EXCEPTION will readily handle.
2) There are a few operations where checking wether they will work
before calling them is as expensive as running the operation. Typical
examples are arithmetic overflow conditions and matrix inversions. In
these cases, the exceptions are raised at the call and should be handled
immediately after the call. Again, the services from EXCEPTION are
sufficient to handle this.

What I think is misdesigned is the retry mechanism - to continue after
an exception, an Eiffel routine *must* restart at its beginning and
successfully run through to the end. Retrying is the right answer in
several cases, in particular if hardware is involved, but there are lots
of other applications, and the retry mechanism makes for some ugly and
needlessly complex control flows. (Which is one of the reasons why
exception processing is done only if necessary, which is exactly a
design goal of Eiffel - maybe the unwieldiness of retry is by design?)

Regards,
Joachim
-- 
Please don't send unsolicited ads.