What would you do with Case Else in a Select Case for a definite list?

Banana

split with a cherry atop.
Local time
Yesterday, 16:03
Joined
Sep 1, 2005
Messages
6,318
I can't seem to make up my mind on how to manage such cases. Usually, it's option groups or comboboxes where entry is required, or perhaps some kind of logic where the choices are always definite and cannot be left blank/skipped/ignored.

In case of an option group, for example, if I somehow ended up in Case Else, this only means something went horribly wrong with the option group and may or may not been user's doing. Thus, displaying a error message would be likely to be more confusing to the user or just annoy the user ("I already selected the friggin' thing and you're telling me you forgot about it?!?"). On other hand, giving a default value may not be desirable. Neither is silently doing nothing as the logic may later depend on a expected value returned from the Case statement.

I think my indecisiveness stem from the fact that I just have no idea what errors I'm supposed to anticipate, because in all probability, the option groups should already have a value selected. (I should rush to add that there is also the assumption that the logic is not executed before the validation has occurred to make sure the value is present, thus making validating in Case Else redundant).

Currently, I just do this:

Code:
....
    Case Else
    'Should not be here!
End Select

So, I'm wide open to any ideas or suggestions here.
 
I would put in the Case Else and set a message box or write to an error log so that you can be aware of any possible value that popped up that you should have handled but didn't. It isn't going to hurt to have it and it might help if you did forget something.
 
That's fine for development, but I was thinking more for production.... Writing to a log is one way of silently recording the problem, and I suppose I could just display a message box saying "The option group's selection was invalid. Defaulting to "X"... If this is not what you want, go back and re-select." so user has a opportunity to fix it in case it's just a hiccup and not a irrevocable defect.
 
Here is a little senerio. I have an option group that prompts the user to select whether the client is taking nicotine replacement therapy (NRT) the options are NRT, Zyban or Champix. there is no default value. One would assume that if no selection was made then the client is not on any of the above, or is it that the user has forgotten to tick the correct option. So for purposes of validation I had to add a further option of "none" so that the user had to state they were doing it cold turkey. Now when the record was being saved if no selection was found then I could tell the user to make a selection first.

One of my problems is that I am too pessamistic and try and come up with every eventuality and try and trap the error. This tends to extend the development period but it pays dividends in the end by covering all bases.

With ref to your select case, else dillema, I have enen put a case else on a Day of Week test, don't ask me why but I always need to have a getout clause.

David
 
you could always put, wherever you are using the option group

if nz(groupname,0)=0 then
msgbox("No Selection etc")
exit sub
end if
 
As you might have guessed from our previous discussion on handling Nulls, I am a firm believer in expecting the unexpected. Having said this, I must point out that your question is really two questions.

1. Should I always include Case Else traps? I say yes.

2. What should I do in case that case crops up? Ah, there's the real question. To which I reply with another question: What do you do in other code when an unexpected condition shows up? I.e. what is your philosophy on "expecting the unexpected" at other parts of your code? Logging? Easy enough. Message box with an "OKOnly" thing? That works. Dialog box with "OK" and "Cancel"? Fine. The idea is that whatever your project, whatever the business model, you should consider error handling as well as handling normal inputs.

Stated another way, what does your business model do when it gets bad data? Well, program whatever your business model would do.
 

Users who are viewing this thread

Back
Top Bottom