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> 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> 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 http://qos.ch/mailman/listinfo/logback-user

---

Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user

On Mon, Aug 15, 2011 at 4:01 AM, Chris Pratt <thechrispratt@gmail.com> wrote:

An error, is an error.  The difference is what you do about it, not what level it's logged at.

But the difference is also how to draw attention to the error. An application can produce hundreds of errors and still work for most users or it can be completely out of order. The difference is not what the app is going to do about, but how do I inform the devops/support about it. In first case it might be sufficient to check the logs in the morning and do something about it during next day, in second case it may be necessary to call someone out of the bed. This difference is 'taken' now :-) The alternative to create a 'fake' appender, call it fatal and log errors to it, seems wrong, but i have no other ideas... regards Leon

On Mon, Aug 15, 2011 at 11:53 AM, Ceki Gulcu <ceki@qos.ch> wrote:

Hi Leon,

I suppose you not familiar with the concept of *markers*.

apparently not, thanx, i will look into it! best regards Leon

You could for example write:

 Marker fatal = MarkerFactory.getMarker("FATAL");  Logger logger = LoggerFactory.getLogger("myLogger");

 try {    ...  } catch (JDBCException je) {   logger.error(fatal, "Lost connection to DB", je);   ...  }

If the you are using PatternLayout, using the %marker conversion specifier will add marker data to appender's output.

You can go even further and add filters or triggers based on markers. Holler for further details.

HTH,

On 15.08.2011 11:14, Leon Rosenberg wrote:

...

On Mon, Aug 15, 2011 at 4:01 AM, Chris Pratt<thechrispratt@gmail.com>  wrote:

...

An error, is an error.  The difference is what you do about it, not what level it's logged at.

But the difference is also how to draw attention to the error. An application can produce hundreds of errors and still work for most users or it can be completely out of order. The difference is not what the app is going to do about, but how do I inform the devops/support about it. In first case it might be sufficient to check the logs in the morning and do something about it during next day, in second case it may be necessary to call someone out of the bed.

This difference is 'taken' now :-) The alternative to create a 'fake' appender, call it fatal and log errors to it, seems wrong, but i have no other ideas...

regards Leon

-- QOS.ch, main sponsor of cal10n, logback and slf4j open source projects, is looking to hire talented software engineers. For further details, see http://logback.qos.ch/job.html _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user