Re: Handling invalid objects

["Randy Brukardt" <randy@rrsoftware.com>]

"Justin Gombos" <rpbkbq.xax.gld@uluv.kbq> wrote in message
news:niWSf.1278$I7.339@trnddc03...
...
> I recall working to a coding standard that barred exception raising
> when other mechanisms for error detection are possible.  It
> effectively banned exception raising altogether because you can always
> send an error notice by other means. Exceptions are synonymous with
> goto statements, with the additional effect of creating an
> unpredictable state so I didn't challenge the rule.

You should have; such a coding standard is brain-damaged. Unless there is a
total ban on exceptions (as in SPARK -- and I disagree with SPARK on that),
there is no good reason to avoid exceptions. It's important that they not be
overused - especially in situations where it is normal and expected that the
failure occur (such as in a Find routine). But it's silly to avoid them,
even in rare but expected situations (such as end-of-file).

Indeed, my view is exceptions and exception handling were one of the primary
leaps forward for Ada over its sibling languages Pascal and Modula. Using
exceptions in cases like this allow the writer of the routine to be sure
that the error is not ignored, causing cascading problems later - and ensure
that the error is localized if it is made.

> Exception raising and handling is often viewed as writing code that
> will never execute.  Predefined exceptions must be handled when there
> is an expectation they will be raised, but their usefullness stops
> there.  Beyond that, it's like writing erroneous code on purpose.

Yikes! I hope you never work for me! I think returning an invalid value on
purpose is like writing erroneous code on purpose. That's because you're
trusting the caller to do the right thing and check something; if you look
at the typical C code, it's pretty clear that doesn't happen much.
Exceptions let you put the error recovery code where it makes the most
sense -- which is usually quite a long ways from wherever the error
occurred. And it doesn't require any trust from the user of your
abstraction. (Note that this still applies even when you are your own
consumer - no one is perfect enough to remember to do things not indicated
in the specification.)

                              Randy.