Re: Handling invalid objects

[Justin Gombos <rpbkbq.xax.gld@uluv.kbq>]

On 2006-03-20, Randy Brukardt <randy@rrsoftware.com> wrote:
>
> 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. 

You would avoid exceptions for the same reasons you might avoid using
a goto statement.  An exception is only a specific type of goto
statement - and gotos are not exactly state of the art.

> 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.

Quite the opposit.  I see neglected potentially raisable exceptions
routinely.  They are particularly easy to ignore - and in fact often
difficult for untrained users to even know they're using something
that would raise an exception.  This makes exceptions the worst kind
of goto.  You can command a jump without even providing a place to go.

It is the alternatives that forces the user of an API to address
problem cases.  In the case of functions, wrapping return data in a
varient record is not something that can be ignored.  Ignoring an
"out" object on a procedure requires cases of neglect to be
deliberate.

>> 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! 

Rightly so.  Bringing me into a sloppy environment with undisciplined
Ada programmers and a mess of spaghetti code could quickly create a
tough environment - and a particularly hostile one if I'm also forced
to do poor quality work myself.  I would not be a team player in that
case, and you should not hire 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; 

It's exceptions that require trust.  In fact, you can ignore an
exception accidentally.  Return a known and documented bad value, or
varient record, and the user must not incompetent to miss it.

Well developed Adaists can pull off using exceptions conservatively
(just like they can gotos), with minimal benefit.  However, you also
can't ignore the fact that most Ada developers are incompetent, and
will write code that doesn't execute, create exceptions for situations
that are not exceptional, and fail to handle exceptions.  I've seen
new developers use exceptions to handle normal operating conditions.
And you can't get away with only letting the advanced users write
exceptions, because their code will interface with that of a
non-proficient programmer.  There are too many gotchas to justify them
in light of better alternatives.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.