You never know if an additional state may be added in the future -- at least by adding something that deliberately throws an error or logs this situation you'll now why something may have silently failed, rather than having that section silently - thus masking a problem - until much later on within the logic flow (i.e. when the problem becomes apparent, it's long past that section of code where the failure originated -- thus much harder to track).

>I agree - I always put exception code even if its never meant to happen.
>
>
>>I believe in "always code for the unexpected". So in cases like this, I usually throw an error message or add to a log file, depending on the situation.
>>
>>>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.