Re: RISC

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

Good points made here. That's kind of why I observed that it is more of an
"art" than a "science". If an engineer has a good sense of what exceptions
are for and how they should be used, he's likely to do a good job with their
usage. However, there aren't a bunch of clear cut rules to apply that always
guide you to proper use of exceptions.

I suspect it would be easier to write a set of rules for proper usage of the
goto statement than it would be to write rules for exceptions. Start with
"never" and then add the handful of cases where it makes sense as exceptions
to the "never" rule. I can't quite get to the same point with exceptions....
(But how's *that* for flame bait? :-)

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/


"Robert A Duff" <bobduff@world.std.com> wrote in message
news:wcczoek12ur.fsf@world.std.com...
> Which leaves open the definition of "error".  Different folks have
> different notions of error.
>
> I think the point of exceptions is that whether a given condition is an
> "error" depends on your point of view.  Eg, a data structure package
> that has a Remove_Item operation: if the data structure is empty, that's
> an error, and an exception is appropriate.  But from the point of view
> of the client, this situation might be "normal" or might be a bug --
> it's the programmer's choice.
>
> 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