Re: RISC

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

It isn't an efficiency issue. Its more of a "design philosophy" issue. If
you are working with systems that have a really high reliability
requirement, you'll get various arguments for and against using exceptions.
(Hard to mathematically "prove" the code, vs "that's what exceptions are
for!" arguments.)

Exceptions can be viewed as a sort of "limited/controlled goto" - and as
such they can pose hazards to good software design. For example, the Text_IO
package will raise an exception if you try to read past the end of a file
because it has no way of knowing what you are attempting to do or why. It
just knows you asked it to do the impossible so it properly throws up its
hands, curses you in exasperation and raises an exception. However, *your*
code ought to know what it is doing with the file and should properly be
checking for End_Of_File as an anticipated condition. You might protect
yourself by trapping any EOF exceptions because you may have made a
programming error and in some corner case you attempt to read past the end
of the file.

Your code should be raising exceptions in similar circumstances - when it
becomes clear that some condition has occurred that is beyond the
understanding and the *responsibility* of the module in which it is raised.
A good example is a function that is undefined for some combination of
parameters. The function in effect says "I have no idea why you sent me this
combination of numbers and there really isn't anyting intelligent I can do
with them to fix the problem and let you press on, so I'm going to raise an
exception that you cannot ignore so you are aware that you probably made a
mistake." The calling code should be trapping exceptions (or not) as a means
of catching unexpected conditions - but not as a normal transfer of control
mechanism. (You would consider it "bad form" to terminate your programs by
dividing by zero, wouldn't you? Same concept here.)

And remember that raising & handling exceptions may or may not be done
depending on the nature of the system. You have to consider this in the
requirements/design phases of the system & plan accordingly. (id est, take a
decision about what exception philosophy should be followed for *this*
application.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/



"Charles Hixson" <charleshixsn@earthlink.net> wrote in message
news:vIYs6.6150$227.669029@newsread2.prod.itd.earthlink.net...
> 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?
>
> 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.
>
> 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.
>
> 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.  And that they should be handled as close
to
> the routine that raised them as possible.  Preferably within the routine.
> But I would hardly call myself an expert at Ada.
>
>