What you describe is an appropriate way if there is no further information assigned with the states such as user locked or user disabled.
If there is, I'd like to suggest an alternative model:
Create an abstract class LoginResultInfo
that has an abstract read-only property of type LoginResult
that will return the "error code".
From that class, you can then derive a subclass for each of the desired error codes. Each of these subclasses overrides the LoginResult
property to return the appropriate error code, and each contains the relevant additional fields, such as a User
instance in the case of a successful login, a text originally supplied by an admin explaining why a user was locked, or the timestamp of when a user disabled their account etc.
With the LoginResult
property, you still have a way to conveniently switch over the different error codes, while at the same time, you don't supply any fields that are used only sometimes, but instead you have a class structure specific and suitable to the situation at hand.