Re: RISC

[Robert A Duff <bobduff@world.std.com>]

Charles Hixson <charleshixsn@earthlink.net> writes:

> Robert A Duff wrote:
> 
> > "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> > 
> >> Its hard to come up with absolute rules since it often requires
> >> subjective, artistic judgements. Just keep in mind that the intention is
> >> to have a mechanism that deals with *errors* - not anticipated conditions
> >> that can be accommodated with some sort of "normal" processing.
> > 
> >....
> > Another way to look at it is that the point of exceptions is to separate
> > the code that *detects* errors from the code that *handles* those
> > situations.  If the code that detects something knows what to do about
> > it, then exceptions aren't necessary -- that code can just have an 'if'
> > statement that checks the condition, and handles the situation in the
> > 'then' part.
> > 
> > - Bob
> 
> Is the problem that exceptions are expensive, or that exceptions violate 
> localization?  Or something else?

I'm not sure which problem you're referring to.  I was just trying to
explain the point of exceptions (ie, why do we have exceptions instead
of just if statements and whatnot).  I wasn't trying to point out any
problem.

> E.g.:  Should EOF detection be done with an exception?  It's usuaual, but 
> expected.  I think of encountering an EOF and an unusual condition, and 
> it's nice to be able to automatically check for it whenever a read happens 
> without explicitly calling on an eof() function.

I prefer the function in the EOF case.

> Java rather expects that procedures will throw exceptions.  I don't know 
> C++ well enough to comment.  Python seems to believe that exceptions are 
> quite reasonable.  Eiffel thinks that exceptions should be handled within 
> the same routine that defines them. Etc.  I think that this is a language 
> specific issue.

True.  But as a language designer by nature, I tend to think about "how
should I design an exception facility", rather than just, "how should
exceptions be used in this particular language", given the biases of
the language designer.

> My impression was that Ada exceptions were intended to handle unusual cases 
> (exceptional cases).  That they were slightly more expensive to raise than 
> a local branch would be, but that they were slightly cheaper if no 
> exceptional case was detected.

Sort of true, except for the "slightly" part.  In a good Ada
implementation, it is enormously more expensive to raise an exception
than to do an if_statement or whatever.  Perhaps 1,000 times more
expensive (just a wild guess).  If the exceptional case is *not*
detected, you still have to execute the compare instruction (or
whatever) that would have detected it, so I see no difference there
(unless you're talking about something like overflow, which can be
detected by the hardware "for free" on some machines).

This efficiency trade-off is because of the intended use of exceptions,
not the other way around.

>...  And that they should be handled as close to 
> the routine that raised them as possible.  Preferably within the routine.  

I don't agree.  If it's handled in the routine itself, why raise and
handle an exception?  Why not just write:

    if X.Length < 1 then 
        Do_Something_About_It;

Exceptions are for the case where the "if X.Length < 1 then" is in a
different procedure than the "Do_Something_About_It;", because the
procedure that detects the error doesn't *know* what to do about it.
I'm not talking about efficiency here -- it would be possible to
implement very-local handlers as efficiently as an if statement /
conditional jump.  But nobody does that, because it's not the way
exceptions should be used.

The "as close to" part of what you wrote is often true.  But there are
certainly cases of handling exceptions very far away: the main program
might handle "others", and then crash gracefully -- it has no idea where
the exception came from.

- Bob