Comments on: 7 Good Rules to Log Exceptions

By: stephan

stephan — Wed, 07 Jan 2009 19:07:47 +0000

@french_c: Oh, don’t tell me about unions. I had a startup which did knowledge management by putting tags (Java, Oracle, …) on people. Unions love that !

By: french_c

french_c — Wed, 07 Jan 2009 18:32:38 +0000

@Bob/@Stephan:

Did you ever talk to labour unions regarding log statements? If not, and your software should run in Germany, you better do:)

Of course you need to be careful logging social, medicial or health related data. But you should also be careful logging user interaction data, which is strictly prohibited in a coporate context (in Germany).

There might be a chance that your labour union will support user interaction tracking that can be used to benchmark employees. But if you are an employer: Better ask upfront! ;)

By: stephan

stephan — Wed, 07 Jan 2009 18:17:42 +0000

@french: Insightful comment as always, thx.

By: french_c

french_c — Wed, 07 Jan 2009 17:16:24 +0000

stephan: Regarding 3bit and “Don’t log an rethrow”.

Log and rethrow Exceptions at system borders is an interesting case. Nevertheless it is a requirement. Otherwhise you end up with a system that is perfectly healthy according to your log (and response time) while being totally broken.

At system borders I tend to log every RuntimeException including its full stack trace (at error level) and every checked exception as part of the API interaction log without a stacktrace (at info level). The “API interaction log” is a simple log statement that tells me which method was executed and whether the execution was successful or not.

Since most remote APIs require centralized API handling code that takes care of exception transformation, stack trace removal, etc. it is easy to add my logging requirements.

By: stephan

stephan — Sat, 03 Jan 2009 06:57:41 +0000

@Bob: Very good comment, the same goes for passwords or (in Germany) other personal information.

By: Bob Follek

Bob Follek — Fri, 02 Jan 2009 23:35:43 +0000

#2 “Store Data…” is excellent advice, but make sure the context info you log isn’t an audit problem. In some businesses, e.g. U.S. financial services, writing a full customer account number to a log file might be a red flag. Consider using just the last 4 digits, etc.

By: Armin

Armin — Fri, 02 Jan 2009 11:50:47 +0000

Hello
it’s very good
thank you sir

By: Interesting Finds: 2008.12.19~2008.12.23 - gOODiDEA.NET

Interesting Finds: 2008.12.19~2008.12.23 - gOODiDEA.NET — Tue, 23 Dec 2008 03:50:11 +0000

[...] 7 Good Rules to Log Exceptions [...]

By: links for 2008-12-21 « pabloidz

links for 2008-12-21 « pabloidz — Sun, 21 Dec 2008 12:06:17 +0000

[...] 7 Good Rules to Log Exceptions Code Monkeyism (tags: programming) [...]

By: Tiago Fernandez

Tiago Fernandez — Thu, 18 Dec 2008 09:00:45 +0000

@Stephan: You’re right, I wasn’t clear enough about that. I didn’t mean to log the stack traces in the functional log, just the user exception message as you said. Cheers.

By: stephan

stephan — Thu, 18 Dec 2008 05:56:45 +0000

@Tiago: I wouldn’t. I would probably log a “User X entered wrong password” but not the exception. There is a difference. The exception has a stacktrace and several causes. User exceptions are quite often and I don’t think most organisations can handle the load of data when logging every exception.

By: Tiago Fernandez

Tiago Fernandez — Wed, 17 Dec 2008 21:18:50 +0000

Great post!

Regarding #1: I agree functional and technical exceptions shouldn’t be stored in the same log file, however user exceptions are useful for helping reproducing issues. IMO they should be logged to a dedicated file (e.g. functional.log).

By: stephan

stephan — Wed, 17 Dec 2008 17:01:25 +0000

@3bit: Yes, then it’s the top layer. At the top layer (EJB at the remote interface or the web layer or the REST layer) you need to log and rethrow.

By: Srikanth

Srikanth — Wed, 17 Dec 2008 16:57:57 +0000

Yes 3bit, that’s an interesting case. But it should be more of an exception than a rule.

By: 3bit

3bit — Wed, 17 Dec 2008 15:09:06 +0000

Sometimes the Anti-Pattern “log and rethrow” makes perfect sense. I case of EJB and remote calls you might want to log the Exception on the server side, but also the client has to be notified of the Exceptional state. If the client has no logging enabled or the log is lost, you can at least fix the server component.

By: links for 2008-12-17 « Brent Sordyl’s Blog

links for 2008-12-17 « Brent Sordyl’s Blog — Wed, 17 Dec 2008 14:05:47 +0000

[...] 7 Good Rules to Log Exceptions | Code Monkeyism 1. Only log technical exceptions not user exceptions User exceptions are either ok and need not to be logged (”login name already exists”) but shown to the user, or no exception at all (”user has no credit left”). Technical exceptions are those you need to debug (”no file storage left”, “could not book product”) and react to. If you log everything you will probably get too many log entries to have a meaningful reaction to exceptions in your log. You should inquire into every exception in your log files and find the cause for it (”is it a bug?”). Too many exceptions will make you sloppy with exceptions in your log files (”nah, just another exception”). (tags: programming exception) Possibly related posts: (automatically generated)links for 2008-07-21Daily Bookmarks 03/26/2008Tags I: Use With Caution [...]

By: Dev Blog AF83 » Blog Archive » Veille technologique :

Dev Blog AF83 » Blog Archive » Veille technologique : — Wed, 17 Dec 2008 12:00:17 +0000

[...] http://www.codemonkeyism.com/archives/2008/12/16/7-good-rules-to-log-exceptions/ : 7 règles à respecter pour logger les exceptions. [...]

By: stephan

stephan — Tue, 16 Dec 2008 21:35:17 +0000

@Andrew: Thanks, fixed, was a newline that wordpress changed to a BR.

By: Andrew

Andrew — Tue, 16 Dec 2008 21:14:49 +0000

Good list – thanks.

Rule #5, there’s a br tag at the end of that hyperlink to OWASP… following it in firefox, it’s a bad title in the wiki.

By: stephan

stephan — Tue, 16 Dec 2008 21:07:14 +0000

@Alexey: Absolutely, you need to check your log. Lots of people don’t check their logs for errors.

By: Alexey

Alexey — Tue, 16 Dec 2008 20:55:17 +0000

I would add: Logging is a michanism of error hiding unless you check you log regularly. The best way to do this is to automate it.

By: Srikanth

Srikanth — Tue, 16 Dec 2008 13:55:42 +0000

>> 6. Don’t log and rethrow

I did that recently and then had to go and remove the clutter :)

By: stephan

stephan — Tue, 16 Dec 2008 13:28:58 +0000

@Albin: I’ve seen #1 several times too

By: Albin Joseph

Albin Joseph — Tue, 16 Dec 2008 12:14:10 +0000

I had seen so many instances of logging exceptions as you mentioned in #1 which makes debugging almost impossible.

#2 is a new learning for me. Thanks for the tip.