A Manifesto For Error Reporting

Re:A Manifesto For Error Reporting by gingerlime on Tuesday March 05, 2013 @09:23AM (#5324587)

I try to apply this to my logger statements. For example:

    unless signals.has_key? key.to_sym
      logger.error("wrong signal received: #{key.inspect} not in #{signals.inspect}")
      raise ActiveRecord::RecordNotFound

Classifying what's an `error`, `warning` and `info` can be confusing some times, but I have quite clear guidelines, and it helps to better deal with errors overall.

error/fatal - anything that I simply can't recover from. e.g. if a parameter is missing, there's no way to even guess. error logging is almost always accompanied by an exception being raised. (btw, on our rails app we use the logging-rails[1] gem, that emails those errors to us)

warning - something seems wrong, but we can somehow still continue, or it's an error that I don't want an email about. For example, blocking spam on a form submission.

info - useful stuff to know what's going on with the app. User registered / logged in, payment received. Those are also sent to graphite for measuring

debug - all the other stuff you need when writing code.

[1]https://github.com/TwP/logging-rails

[ Parent | on HN ]

Re:A Manifesto For Error Reporting by adrianmsmith on Tuesday March 05, 2013 @01:05PM (#5326173)

Yes I've thought about this topic as well.

All loggers in all languages have these different levels. But rarely is it defined which to use when! It's considered "obvious" but, unless it's actually defined, each programmer will find it obvious in a different way. Reading the logfile in production or using rules to only display logs beyond a certain severity won't be useful if every piece of code uses different levels to mean different things.

Here are the rules I came up with:

http://www.databasesandlife.com/which-log-levels-to-use-when...

[ Parent | on HN ]

Re:A Manifesto For Error Reporting by gingerlime on Tuesday March 05, 2013 @02:48PM (#5326869)

looks like we have the same idea of which levels makes sense. It's surprising how many developers don't bother thinking about it or realising the importance of logging in general, and consistent logging in particular.

[ Parent | on HN ]

Re:A Manifesto For Error Reporting by pjungwir on Tuesday March 05, 2013 @01:00PM (#5326136)

That Ruby logging framework looks really nice. But from reading the READMEs, something seems missing: is there a way to set the log level for different appenders (rather than different classes)? For example, you want the `file` appender to keep everything, but the `email` appender should only report errors.

[ Parent | on HN ]

Re:A Manifesto For Error Reporting by gingerlime on Tuesday March 05, 2013 @02:46PM (#5326853)

yes, that's the way it works pretty much. Appenders are independent and you can pick and choose. I've defined it to only send an email when errors are logged, but everything goes to a file.

It also has a nice feature that it won't bombard you with an email for each error, but instead it collates the errors and only sends an email after 60 seconds (configurable too).

I really recommend this gem. While you're at it, try out lograge gem too, which makes logs much more compact. Both gems work well together.

[ Parent | on HN ]

Re:A Manifesto For Error Reporting by pjungwir on Tuesday March 05, 2013 @05:29PM (#5327843)

Do you have to do anything special to get that behavior from the email appender? I can't find anything in the docs about setting appender-specific log levels.

[ Parent | on HN ]