After having implement several real-time debuggers for military
systems (and lurking for months on this list) let me weigh in.
First, the "Severity" of an event is one of many attributes.
The attributes include an event name (including a subject),
time, the host, the environment, a descriptive string, an
instance of an object, etc.
Second, the Severity is a tricky business to get right. As has
been observed, one person's "Fatal" is another person's
"Warning". Depends on context. I can remember putting in lists
of overrides that would treat ordinarily fatal OS exceptions as
warnings so our application could continue to run in spite of
lossed I/O interrupts.
Third, all programming boils down to comparison of integers. If
we start from comparison of integers, we've lost any possibility
of putting more meaning into the program. If we start with
class definitions, then the final implementation may be some
kind of RTTI that is implemented as an integer comparison.
Fourth, all logging systems need filters. Often those filters
are subject-area based, and have little to do with severity or
with the ultimate exception/error class to which the event
belongs. For "normal production" we only want to see severe
errors or fatal errors that are the final outcome of the
application. For "QA testing" we want to see all errors from
all component modules. For "Integration testing" we want to see
all warnings from all classes. etc.
Simple numeric codes won't provide much useful filtering.
Programmers will work around it by dynamically assigning a
severity to permit logging under some circumstances. People
will build applications that use an environment variable to set
message severity so that it will be very severe during testing
(and get logged) but not severe in production (to reduce the log
blather).
A subject area string (or tuple) is a cool way to do business.
It allows one to label the event with information like module,
class, method, event. If someone wants to include severity as
part of their subject string, that's good. Then you can filter
on subject areas.
The idea is to use a simple fnmatch-style filter.
log.watch( 'error.*' ) or log.watch( 'warn.*', 'error.*' )
or log.watch( 'error.pil.gif.*' ).
I'm not the only one who's found this effective. If you dig
into the TIBCO commercial product, they devote some real energy
to making useful subject names for the message traffic in their
middleware product.
My vote is:
A) existing exception/error hierarchy
B) LogEvent class with message string, subject string, delayed
introspection, automatic timestamping. LogEventObject and
LogEventEnviron subclasses would drag around additional details.
C) The logger would filter LogEvents based on subject string.
Since each event is an object, the logger could simply pickle
the events, or write their __str__ to stderr.
=====
--
S. Lott, CCP :-{)
S_LOTT@YAHOO.COM
http://www.mindspring.com/~slott1
Buccaneer #468: KaDiMa
Macintosh user: drinking upstream from the herd.
__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4