Runnable’s and logging Exceptions

When creating Runnable’s (or other task related structures like Callable’s or your own Threads), make sure that you are logging exceptions. This week I was asked by a colleague to assist with a possible concurrency problem. The symptom was the disappearance of running tasks.

We added some extra debugging statements and added the name of the thread to the logging, but we still were not able to find the cause. After 15 minutes we figured out that the cause could be an exception that was not logged and therefore not visible in the logging. So we added a try/catch block around the content of the runnable, ran the application, and what do you guess? In the log stacktraces started to appear.

So when you are in charge of the top of the callstack (so running your own threads) make sure that you catch and log exceptions. If you don’t, it could lead to hard to find problems.

Code Quality: Care about your name

One of the things most of us encounter from time to time is bad naming in source-code. It could be a package, interface, class, method or variable, but when you have it in your system, it can irritate, or cause more serious problems like code duplication (DRY) and perhaps slowing you down. Even worse is a class with a misguiding name because people are put on the wrong foot, especially when they are new or not touching the code regularly.

That is why I take a step back and see if the name is intent revealing. In some cases a better name is found later (throw it in the team). And with all the refactoring support in new IDE’s, renaming almost always is not a issue and should be picked up asap. Especially when its a leaf in the system (something deep down) I do it immediately to reduce technical debt.

When the concept the name represents, for example a Listener, is used more than once in your system, make sure it is used consistently so you know what to expect. According to the timeless Unix philosophy this is called: ‘The rule of least surprise’. In some cases a good name depends on knowledge (e.g. perhaps you know it as an some kind of pattern), so a good name can be subjective. When it could be unclear to others, I add it to the documentation.