How convince other developers not to ignore Exceptions?

Question

Recently I encountered a bug in an application I took over from another developer. I debugged for the reason and over an hour later I realized, that the problem wasn't the code producing the exception, but some code executed before this returning wrong data. If I dived into this, I encountered the following:

try {
  ...
} catch (XYException e){}

If the Exception would have been propagated (a change I did), I would have found the reason for the bugs in a few minutes, as the stacktrace had pointed me to the problem. So how can I convince other developers to never catch and ignore exceptions in this way?

Answer 1

Simple rule of thumb: catch exceptions if and only if you have a meaningful way of handling them. Do whatever you need to do at your workplace to propagate this simple rule.

By utilizing tools such as PMD, you can even enforce this in the development environment of all your developers. EmptyCatchBlock (first rule under Basic Rules) is a rule that does exactly what you need. You have some more out-of-the-box rules for exceptions if you need better control on exception handling.

Nevertheless, in my experience, enforcing the use of tools such as PMD is never a substitute to proper development practices and developer education.

Answer 2

Start BadHumour:

Add a silent critical exception into the code that causes the application to shut down, and
let them sit and cry trying to find it for about an hour - Then educate

End BadHumour

The simple rule is simple: Use exceptions for exceptional circumstances. Anything else is silly and wasteful. Compare swallowing of exceptions to eating candy coated razor blades. They may taste nice now, but wait until they start to be digested. (Coding Test system vs. Debugging Live system)

Answer 3

There are some subtle ways to that (each of those being subjects to discussions)

• Make all your application's Exception RuntimeException subclasses. This way, there is no try/catch in your application, and you can easily see (at the thread level) what problème broke the thread. Unfortunatly, this has no effect on the developper that wrote this code block precisely to get rid of an exception he didn't bother to manage.
• Use Checkstyle, or an other static code checker, to ensure no empty catch block exists in your application. Unfortunatly, this do not works when no continous integration process exists in your team (since errors notification won't go to the developper responsible for them).
• Provide default catch template code with a sensible value (like a logger.log(Level.WARN, "something went wrong here", e)) allowing user to not have to worry about exception management, however having a reasoably good code.

Answer 4

Point them to this link http://www.ibm.com/developerworks/library/j-jtp05254.html an article which explains when to check or uncheck or throw or catch :)

Answer 5

Simple point - have the lead developer declare that. Catching an exception and swallowing it without reason is equal to sabotage and should lead to recursion against the developer (i.e. talk i nHR about his attitude).

As Yuval said, catch exceptions only if you actually do something sensible. let things bubble up if you dont know what or how to handle them. POSSIBLY wrap them in other exceptions IF expected (i.e. a DAL may throw a DataLayerException so that higher up levels can handle all that stuff in one try/catch, but it would not handle something unexpected).

it is a ridiculous way to catch exceptions and swallow them.

Answer 6

The same way you convince other developers to follow any sort of best practice. This particular anti-pattern is a fairly common (and extremely painful!) one, but there's countless other examples of bad coding practices that are probably at least somewhat common among your team members.

In order of difficulty in getting started, here's some recommendations I've seen used effectively in the past:

1. Talking to the developer, pointing out the problem, and describing how it caused problems for you. The simplest solution - not always effective, and it will only work for that one developer, but it's better than doing nothing.
2. Public shaming. I've worked in places where we had a "Wall of Shame" with various coding horrors from our project, along with the developer who wrote them. It's really important that this is done in a lighthearted way, and it's really something I wouldn't advise just starting without getting everyone on board, but it's a fun way to point out issues like this.
3. Reading groups. If you have the means to get a lunchtime reading group started at your office, I highly recommend it. Coding issues like this would be addressed extremely well by a reading group going through "The Pragmatic Programmer".
4. Code reviews. Again, not the simplest thing to get started if you're not a team lead, but it's absolutely worth a suggestion to yours if you aren't one. If you are a team lead, you should have started code reviews yesterday.

Answer 7

One nice feature I like about the VS.Net debugger is that you can tell it to break when any exception is thrown. It isn't something you would turn on all the time, but can help when you're trying to hunt down a particular bug. I wonder if the same feature exists for Java, since it is an environment very similar to .Net. I think this problem shows up more in Java than it does in .Net however, because Java requires you to handle exceptions, or to at least mark your method as throwing the same exception (AFAIK). So, if you are required to handle it, a lot of bad developers will just swallow it, because they have no idea how to handle it, or what to do with it.

None of this really helps you stop bad developers from doing bad things. I think the best thing you can do, is to do code reviews. Encourage coworkers to look over the list of check-ins to ensure that things are done correctly. With a good source control system, this can be done pretty easily. And human eyes can catch things that computers can't. A computer would be able to delete an empty catch block, but humans can catch a whole lot more antipatterns.

Answer 8

The title does not match the example. In the example the exception is not ignored but handled in a nasty way (this is sometimes referred to as exception swallowing). For this particular malady I recommend static code analysis and bonus/salary reduction.

Answer 9

Charge the time against the developer concerned, or the module concerned, rather than yourself, or your own module.