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: [email protected] [mailto:[email protected]] 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 <[email protected]<mailto:[email protected]>> wrote: +1 I have the exact same question Sent from my iPhone On Aug 14, 2011, at 7:14 PM, Leon Rosenberg <[email protected]<mailto:[email protected]>> 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 > [email protected]<mailto:[email protected]> > http://qos.ch/mailman/listinfo/logback-user _______________________________________________ Logback-user mailing list [email protected]<mailto:[email protected]> http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list [email protected] http://qos.ch/mailman/listinfo/logback-user
