This is a general question of philosophy. I've received instruction from various people over the years to go one way or the other. Some have said always code for the unexpected condition. Others have said it's unexpected, should never happen, is in error and should crash. This has been in various languages.

I'm curious what the consensus is from VFP experts.

Suppose I have a value that should always be only 1, 2, or 3. It represents the state of something. Let's say 1=in cart, 2=ordered, 3=shipped. It should never be any other value.

In your code do you code for the OTHERWISE clause?

DO CASE
    CASE nStatus = 1
        * It's in cart ... process it thusly
        process_in_cart()

    CASE nStatus = 2
        * It's ordered ... process it thusly
        process_ordered()

    CASE nStatus = 3
        * It's shipped ... process it thusly
        process_shipped()

    OTHERWISE
        * Should never happen ...
ENDCASE

Is the OTHERWISE clause needed there? Is it only needed if there's logic below that depends on the state?

And what about cases like this:

lnValue = 1   && Should only ever be 1, 2, or 3

DO CASE
    CASE lnValue = 1
        * Process as 1

    CASE lnValue = 2
        * Process as 2

    CASE lnValue = 3
        * Process as 3

    OTHERWISE
        * Should never happen
ENDCASE

Do you need an OTHERWISE here? It's been explicitly set to a value that's known to be in the range of testing values. I always err on the side of caution. The extra OTHERWISE clause should never be hit, but if it is ... it will catch unexpected conditions. I usually put a function call in there called silentError(), which will trap through to a single handler allowing me to catch errors that should never happen, and record their code location, etc., during development, and log the same during production.