A Manifesto For Error Reporting

I'd expand on one of his points and observe that one of the core problems is that they are called <i>exceptions</i>, which prejudices the discourse in advance. They <i>aren't</i> exceptions. They are a way of declaring a handler that is scoped to receive certain types of objects on a second control plane (beyond normal control flow), which when invoked, destructively unwinds the stack until a matching handler is found or the program terminates due to falling off the top.<p>That is what they <i>are</i>. One of the things this mechanism is <i>used for</i> is exceptions, but that is a separate concept. It is possible that exceptions are generally a good idea, but that is the wrong mechanism to use for them (see, for instance, Lisp conditions &#38; restarts for a good argument to that effect [1]). It is also possible that exceptions in general are a bad idea and it is better to use inline error codes rather than the separate control plane <i>but</i> that there is some other valid use for this second control plane (see all the non-exception uses of "exceptions", and note this is not hypothetical; see Python's StopIteration exception [2]).<p>Conflating the feature with the most popular use just leads to lots of confusing debates with people talking past each other.<p>[1]: <a href="http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html" rel="nofollow">http://www.gigamonkeys.com/book/beyond-exception-handling-co...</a><p>[2]: <a href="http://www.python.org/dev/peps/pep-0234/" rel="nofollow">http://www.python.org/dev/peps/pep-0234/</a> , use Find to search for "It has been questioned" for a direct response to this issue

&#62; If you catch an exception, I need to know about it unless you’re really goddamn sure I don’t<p>I don't think I agree with this one. We agree that when a piece of of code encounters a problem it should trigger an exception with stack trace and useful information. But you seem to believe that when an exception handler catches an exception it should log it, then do something about it. I think that exception handlers should do one of two things:<p>(1) Catch the exception, add additional information that the lower-level function didn't have access to (eg: what file was being processed when it occurred), then re-throw the exception.<p>(2) HANDLE the problem somehow.<p>(Anything else and you just shouldn't handle the exception.)<p>Now, (2) has several possible things. Perhaps if the web service is down we can fall back on using the cached values from the database -- that's an example of FIXING the problem. Perhaps the value isn't really needed and we can leave it out -- that's AVOIDING the issue. And the most common is to show an error message to the user in one form or another -- that's REPORTING it.<p>If you REPORT the problem, I believe you should always output the exception and stack trace someplace. But if you FIX or AVOID the problem, then it may or may not be appropriate to log it. A FIX or AVOID situation that occurs quite rarely is probably worth logging; one which occurs under normal circumstances (the web service goes down for maintenance for several hours each week) may only need a counter in some admin console.<p>(PS: using exceptions as control flow is an extreme case of FIX -- reaching the end of the list was an exception that is FIXED by moving on to the next piece of work.)

I try to apply this to my logger statements. For example:<p><pre><code> unless signals.has_key? key.to_sym logger.error("wrong signal received: #{key.inspect} not in #{signals.inspect}") raise ActiveRecord::RecordNotFound </code></pre> 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.<p>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)<p>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.<p>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<p>debug - all the other stuff you need when writing code.<p>[1]<a href="https://github.com/TwP/logging-rails" rel="nofollow">https://github.com/TwP/logging-rails</a>

Lots of good advice. I am constantly amazed at how many error messages don't contain any dynamic information (as mentioned in the article - what the offending value was, and why it was wrong).<p>One of the best fixes is for developers to have to spend time debugging/trouble shooting. If nothing else, it teaches you the importance of good error/log messages.

God knows I've seen enough "two year old" error messages: "I don't like it! &#60;spits out&#62;". Well, what <i>would</i> you like, you sniveling little diaper wetting sot of a program?!?<p>I could not agree more with his comment about "Bad value {X} should be ...".<p>Oh, and the part about the amazing disappearing stack trace -- I've seen way too much "print e.toString()" which discards all that wonderful "where" information.

Python specific advice on re-raising upon catching and keeping the original trace: in Python 2.7+, please use chained exceptions: <a href="http://www.python.org/dev/peps/pep-3134/" rel="nofollow">http://www.python.org/dev/peps/pep-3134/</a><p>For older Python versions please see <a href="http://blog.ianbicking.org/2007/09/12/re-raising-exceptions/" rel="nofollow">http://blog.ianbicking.org/2007/09/12/re-raising-exceptions/</a>

When I'm coding I normally think about 2 things:<p>- What should I do here to help me and other developers understand what's gone wrong. This generally results in one of the three categories:<p><pre><code> - Is it a "shouldn't happen" error like hardware malfunction, internet down, etc. - Is it a invalid data error, someone screwed data and I got the error here. - Is it a algorithm error, I got something wrong in my code and this wasn't supposed to happen. </code></pre> - What should I show to my user. Divided in three categories too:<p><pre><code> - Unrecoverable error: should show a big red screen. - Recoverable error: should show a informative message with instructions. - Errors that don't affect the user: no need to show anything, just log the error.</code></pre>

What I think is that, depending on your users though, they do not understand your backend enough to make proper error reporting.<p>The "Bad argument" example, they don't know how many different situation triggers the same error, they don't know if what they did before will help you figure out their problem. In short, they don't know enough to be helpful.<p>I don't have any great solution to this, but putting a middleman who, although can't help you with programming, knows what is helpful and what is not enough to provide useful error reporting to you might solve it.

This is why we had a logger running in the background that received all anomalous events from warnings to exceptions (the class, method and passed data including passed parameters and the relevant line). And we had a catch-all trigger for when something goes really, really, really, badly wrong and there's nothing else available to dump to the logger.<p>Annoying during development, a godsend in production. No one is immune from stupid mistakes.

Windows developers have it easier because debuggers are better. The same debugger can work on VB6 code calling C++ calling C#. Memory dumps also seems to be more common and useful in Windows than in Unix. If you get dump for all crashes, stack traces seem almost useless in comparison.

The only tragedy about this thread is that more people aren't commenting. Either people are taking the advice and moving on or they don't care. I really hope it is the former :)