
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. Brett From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@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. (*Chris*) On Sun, Aug 14, 2011 at 5:55 PM, Jason Berk <jasonrberk@gmail.com<mailto:jasonrberk@gmail.com>> wrote: +1 I have the exact same question Sent from my iPhone On Aug 14, 2011, at 7:14 PM, Leon Rosenberg <rosenberg.leon@gmail.com<mailto:rosenberg.leon@gmail.com>> wrote:
Hi,
since logback doesn't support log level FATAL I'm wondering how you guys are separating between 'normal' errors and 'really bad' errors. Example: 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 Leon _______________________________________________ Logback-user mailing list Logback-user@qos.ch<mailto:Logback-user@qos.ch> http://qos.ch/mailman/listinfo/logback-user
Logback-user mailing list Logback-user@qos.ch<mailto:Logback-user@qos.ch> http://qos.ch/mailman/listinfo/logback-user