LogLevel.None

[WilBloodworth]

Please either change LogLevel.None's value to 0 or provide a different log level that has a value of 0.

Right now, there isn't an entry in this enumeration with the value of 0. I consider this an error even though it is allowed (i.e. compiles). For example, if you take, "default(LogLevel)" what does it return?... 0. But 0 isn't a valid value for LogLevel.

Please simply change None to be 0 and all will be right with the world. I honestly don't care which way you change the ordering (low to high), (high to low)... as long as this enumeration ends up with an entry with a 0 value.

SIDE BAR: You could make it a 'flags' enumeration with values having the power of 2... that way you COULD mix and match the levels. Not sure who would do that... but you could.

Thank you!

[benaadams]

SIDE BAR: You could make it a 'flags' enumeration with values having the power of 2... that way you COULD mix and match the levels. Not sure who would do that... but you could.

Might work for listeners/loggers that want a couple levels but not others

[muratg]

@lodejard How about starting with -2 for Trace, and having 0 as Information?

[muratg]

@WilBloodworth using default on an enum is not a common case, AFAIK. What's the use case where you would do default(LogLevel)?

[muratg]

We had a discussion on this with @glennc and @lodejard.

@BrennanConroy let's remove the number from the enum, and leave "None" at the bottom (because it has to be the largest.) Make sure to put a comment to remind folks keeping "None" at the bottom with any future change.

[NickCraver]

@muratg I don't think removing the numbers is the best approach here. Without numbers, you're going to get automatic numbering and (potentially) break any library that wasn't recompiled to handle the change later and definitely complicate handling of previously serialized data.

Let's say you insert a new level above Critical, if someone has compiled for None previously, they'll be handling a new log level that wasn't intended. This happens for example when serializing the enum as an integer and back (which is far more space efficient for storing things like exceptions). Putting explicit numbers on an enum is precisely how you prevent this situation...I strongly suggest against removing them. Where None lies doesn't bother me much, but it should be constant. If anything though, I'd agree with None being at 0, that's a pretty common convention and the expected position - it also avoids any complications with additions later and (if it were serialized) allows a much smaller integer type to be used (e.g. tinyint in the database rather than a full int - this shouldn't happen in any case I can think of, but that's why you rarely file an enum with a crazy-high value).

[Eilon]

I definitely wouldn't remove the numbers. All enums should always have all values with explicit numbers.

[304NotModified]

I definitely wouldn't remove the numbers. All enums should always have all values with explicit numbers.

Agree with this one.

Somewhat related, in NLog we choose not to use enums at all for the LogLevel, see code. This because of extensibility.

[lodejard]

Okay, chatted with some folks, sounds like the proposal would be adjusted slightly to this straw man:

• Keep the explicit constant numeric values in the declaration
• Start with 0 as Trace so that default(LogLevel) gives you a value that's in the set
• Don't skip to int.MaxValue - instead have None be one higher than Critical.

Trace=0,Debug=1,Information=2,Warning=3,Error=4,Critical=5,None=6

[muratg]

Does this mean if at any point we add a new level, we'll add it at the end with number 7?

[benaadams]

Does this mean if at any point we add a new level, we'll add it at the end with number 7?

Could skip some?

Trace=0,Debug=4,Information=8,Warning=12,Error=16,Critical=20,None=24

[lodejard]

Oh, guys... 😫... Are we certain this is a place that needs future-proofing?

If so I believe the way that turns out is closer to what NLog and log4j have implemented. As an immutable LogLevel class with pre-defined public static constants for the assorted levels, integers that skip by a large number, and convenience methods on the LogLevel class to help correctly implement a mapping from a given LogLevel value to a provider-specific enum member.

See also http://svn.apache.org/viewvc/logging/log4j/trunk/src/main/java/org/apache/log4j/Priority.java?view=markup and http://svn.apache.org/viewvc/logging/log4j/trunk/src/main/java/org/apache/log4j/Level.java?view=markup

Though TBH IMHO if we did all that work I don't predict we'll ever end up doing more than this enum currently represents.