Re: Handling invalid objects

[Brian May <bam@snoopy.apana.org.au>]

>>>>> "Justin" == Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:

    Justin> The 'Valid attribute exists to be able to handle abnormal
    Justin> objects.

    Justin> Here's a concrete example.  Suppose I have:

    Justin> type clock_type is mod 12;

    Justin> function hour_of_day return clock_type;

    Justin> If hour_of_day gets called and for whatever reason I
    Justin> cannot return an hour_of_day, the caller needs to know
    Justin> that.  Exceptions are a poor choice.  The quality and
    Justin> style guide advises against them for a good reason;
    Justin> exceptions are like gotos - and produce a questionable
    Justin> state.  It would be more graceful for me to return an
    Justin> invalid value (like -1), so my caller can simply do a
    Justin> 'Valid to discover whether the operation was successful.

If you returned an invalid value, I would consider that a breach of
the contract you established where you declare you only return a valid
clock_type.

This is similar to a problem I have seen when tutoring C++, students
get stuck on the problem that looks something like this:

item &find_item(...) {
     
     ... search for item ...

     if (found) {
        return item;
     } else {
        return ????;
     }
}

The ideal solution would be exceptions, but the students haven't been
taught exceptions yet when conducting this exercise.

Another solution would be to change the API to return a struct value,
but students are told they cannot change the API.

So students typically hard code it to return the first item, on the
assumption that there is a first item. Either that, or simply omit the
return statement, and ignore the compiler warning. Not good
programming practise either way...
-- 
Brian May <bam@snoopy.apana.org.au>