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

It is a good practice to always have the otherwise.
1. The first thing is to admit that none of us codes 100% bug-free code.
2. If you NEVER make a mistake, not ever, please refer to #1
3. Always assume the code will be changed later - maybe by somebody else after you retire to your own private island.
4. When the code is changed, there may be new values that somebody forgot to change the CASE statement for a new value.

My very first programming job, I will have to admit, I was writing buggy code.
Our team leader suggested that I always have a trap for the "impossible" case.
I argued that these cases were impossible - and he said "It is good practice, and that otherwise will never be hit, and it is no harm to have 2 more lines of code."
I just put MessageBox() in the otherwise with the name of the function and the unexpected value.

There were a few otherwise clauses that never did get hit.

However!
I still blush when I think of how often those otherwise messageboxes DID get hit.