Is there any harm in having many enum values? (many >= 1000)

Question

I have a large list of error messages that my biz code can return based on what's entered. The list may end up with more than a thousand.

I'd like to just enum these all out, using the [Description("")] attribute to record the friendly message.

Something like:

public enum ErrorMessage
{
     [Description("A first name is required for users.")]
     User_FirstName_Required = 1,
     [Description("The first name is too long.  It cannot exceed 32 characters.")]
     User_FirstName_Length = 2,
     ...
}

I know enums are primitive types, integers specifically. There shouldn't be any problem with that many integers, right?

Is there something I'm not thinking of? It seems like this should be okay, but I figured I should ask the community before spending the time to do it this way.

Does .Net care about enum types differently when they have lots of values?

Update

The reason I didn't want to use Resources is because

a) I need to be able to reference each unique error message with an integer value. The biz layer services an API, in addition to other things, and a list of integer values has to be returned denoting the errors. I don't believe Resources allows you to address a resource value with an integer. Am I wrong?

b) There are no localization requirements.

Answer 1

1000 is not many, you should just make sure that the underlying integer type is big enough (don't use a char for your enum.

On second thought 1000 is tons if you're manually entering them, if they are generated from some data set it could make sense kinda...

Answer 2

I think a design that has 1,000+ values in an enum needs some more thought. Sounds like a "God Enum" anti-pattern will have to be invented for this case.

Answer 3

The main downside I'd point out with having the friendly description in an Attribute is that this will cause challenges if you ever need to localize your app for another language. If this is a consideration, it would be a good idea to put the strings in a resource file.

The enum itself should not be a problem, though having all of your error codes in one master list can be confusing. You may consider creating seperate enums for seperate categories of return codes, as this will make it easier for developers to understand the possible return values for a particular function. You can still give them distinct numeric values (by specifying the numeric values explicitly) if it's important that the codes be unique.

On a side note, the .NET BCL does not make much use of return codes and return codes are somewhat discouraged in modern .NET development. They create maintainability issues (you can almost never remove old return codes or risk breaking backwards compatibility) and they require special validation logic to handle the returns for every call. Stateful validation can be accomplished with IDataErrorInfo, where you use an intermediate class that can represent invalid states, but that only allows a Commit of changes that are validated. This allows you to manipulate the object freely, but also provide feedback to the user as to the validity of its state. The equivalent logic with error codes often requires a switch statement for each use.

Answer 4

I fully agree with duffymo. An enum with 1000+ values smells bad from y design point of view. Not to mention that it would be quite nasty for the developer to use intelligence on such a GOD ENUM:-) I would better go for using resources.

Answer 5

I think it's very bad, for error handling you can simply use resource, as i see you want to do reflection and fetch the description its bad too. If you don't want to use resources, you can define different enum for each of your business rules, Also your different business doesn't need others error message (and shouldn't be like this).