Strategies for Rails Logging and Error handling

Today I have some questions about how the logging is doing in our project – Techlist. From Justin, he said that we don’t usually log the exception by catching them in the rescue block but use some gem for automatically handle this for us, Redis, for example, not sure if I really catch what he means :D. From my past projects with .NET, I logged the exceptions and stack trace to db, then I find it’s really easy for me to figure out what was wrong, so I think it’s really weird, especially for RoR, so I decided to investigate to this topic.

After reading some blogs, I think it is worth to write down what I leant. For all products we release to customer, it’s really bad if we don’t know what was wrong, where it happened, it’s even worse if:

1. You don’t have a clear log message that identify exactly what went wrong

2. You didn’t get automatically notified via email that something went wrong. Instead, the customer told the customer service rep that there’s an issue, the responsible developers should be notified

You see, logging is indeed important for every projects, RoR is not an exception also. However, logging is art, yeah, and developer who writes log appropriately is an artist, j/k. I will not mention about how to setup logger in this post, google is free. I will just quote the “logging strategy in rails” got from this blog.

Avoid rescuing/catching if you can’t do anything with the exception. For example, in a model method, you might be calling that from a controller, but you also might be calling that from some scheduled job. Thus, it’s hard to say what the right action should be. A special case is calling raise without arguments: sometimes it is reasonable to catch all exceptions, logging the exception, and then re-raising it like it was never caught.

If you catch an exception, consider if you should re-throw the exception because code at a different level will be able to handle the exception more properly.

Consider how the code is being invoked, such as from a call to generate HTML or an ajax request, or maybe a batch job. All of these cases have very different needs for how the error should be handled.

Be sure you understand the order of your rescue clauses matter. This article The Universe between begin and end provides a good explanation. Basically put the most specific exception types first and something like rescue => e last.

Ruby does not support the concept of a “cause” with an exception. Thus, if you catch an exception and are going to re-throw a different exception, then it’s important to log the stack of the original exception, or else that information will be lost.

Test the logging of the exception in both development and production mode. You want to ensure that any exception prints clearly regardless of Rails environment.

A good way to test error handling is to temporarily put in raise ArgumentError (or whatever other error), and see how the exception is handled, both by the logger and the UI.

The worst scenario is catching an exception and failing to log any messages. This can make troubleshooting a problem very tricky.

That’s all, you may say that “hey, why did you write it in English, your readers are Vietnamese”. Hmm, the reason is that I’m so lazy to translate the “quoted content” to Vietnamese, so I chose English, even my English is not very good, lol. Forgive my laziness, please :D