[logback-user] Best practices for FATAL errors...
brett.walker at geometryit.com
Mon Aug 15 04:08:13 CEST 2011
I agree with you Chris in so much that a fatal error is really what you do about it.
And logging is to support the application. The application is really going to be doing something
atypical on a fatal error rather than an ordinary error. This needs to be highlighted in the logs.
The level of the log message should reflect the nature of the message.
From: logback-user-bounces at qos.ch [mailto:logback-user-bounces at qos.ch] On Behalf Of Chris Pratt
Sent: Monday, 15 August 2011 12:01 PM
To: logback users list
Subject: Re: [logback-user] Best practices for FATAL errors...
An error, is an error. The difference is what you do about it, not what level it's logged at.
On Sun, Aug 14, 2011 at 5:55 PM, Jason Berk <jasonrberk at gmail.com<mailto:jasonrberk at gmail.com>> wrote:
I have the exact same question
Sent from my iPhone
On Aug 14, 2011, at 7:14 PM, Leon Rosenberg <rosenberg.leon at gmail.com<mailto:rosenberg.leon at gmail.com>> wrote:
> since logback doesn't support log level FATAL I'm wondering how you
> guys are separating between 'normal' errors and 'really bad' errors.
> Warning: tried to insert statement into db, found key conflict,
> resolved it (somehow).
> Normal errors: couldn't insert the statement into db because the
> encoding is invalid (or couldn't read user's file because its corrupt)
> - affects one user.
> Really bad errors: have no connection to db, so my further existence
> is rather meaningless.
> So how do you guys log fatal errors without fatal? .-)
> best regards
> Logback-user mailing list
> Logback-user at qos.ch<mailto:Logback-user at qos.ch>
Logback-user mailing list
Logback-user at qos.ch<mailto:Logback-user at qos.ch>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Logback-user