Of course nothing would throw exception or otherwise indicate invalid enumeration value unless you do it by yourself.
However, you should think about it: do you really need a guard against such cases? Indeed, how such cases can appear? For example, you can develop some code which calculates some integer value, and then type-cast it to your enumeration type, to call your method. Naturally, this is the risk of getting the value out of the valid set.
A resolution? Don't do evil (in this case, type cast from integer), and you won't have a problem.
Another case is: the values comes from the stream from some other process, via network. It is possible that the sending process is running on some other machine, where you use obsolete or newer library, an assembly where your enumeration type is defined. Then again, if the enumeration type is different on different sides of the network application, the value out of valid set of enumeration values (for one of the sides/version) is quite possible.
A resolution? Don't be sloppy, and you won't have this problem. How? Don't work with incompatible version. Create a mechanism of incremental version update, a mechanism checking up all versions of all assemblies (through reflection) and sending this version information through network for rigorous check-up.
And finally, the whole idea of your long case statement comparing value with separate enumeration members is not a very good idea. Please see my articles explaining some
more advanced and less meticulous and less error-prone techniques:
Enumeration Types do not Enumerate! Working around .NET and Language Limitations[
^],
Dynamic Method Dispatcher[
^].
—SA