Dirk's employer bought some software from a vendor, and the vendor promised that it was a cutting edge system, which was pushing the boundaries of technology. Digging through the API documentation, Dirk definitely found some unusual innovations, like the way it tracked log levels:
[FlagsAttribute]
public enum TraceEventType
{
NoTracing = 0,
Critical = 1,
Error = 2,
Warning = 4,
Information = 8,
Verbose = 16
}
Your boring old software treats log levels as, well, levels. A message exists on a level, you filter for a certain level, so if you only want Error
messages, you won't see Debug
messages, but if you Debug
you'll also see Error
s.
This cutting edge system lets you decide what message you want to see, because message levels are bitmasks. You want critical information? Look for 9
. You want only critical warnings, whatever that may actually be? 5
it is. And does a 6
tell you that the warning was an error, or that there was an error outputting the warning?
And yes, most methods that involved logging let you log a message with any integer combination, and most that involved filtering logs let you filter with a bitmask. Unfortunately, not all of them did, and the behavior of "filter by bitmask" was inconsistent, as most of the logging engine assumed you wanted to filter by levels, so a filter of 17
might, in some cases, only show critical messages.
Such is the path of true pioneers: their brilliant idea is held back by systems that are entrenched in the "old" way of doing things. Or maybe someone just didn't really understand how log levels and enums were supposed to work and just made a bitmask by accident.