Java exceptions are a powerful tool for making sure that your code completes successfully and that issues are handled tidily by your code. The problem that I often see is that people don’t often design their exception handling policies so that they are dealt with in a uniform manor and that when things do go wrong they don’t translate coding problems into something the user can understand. Here ill go over a solid design principle for exception handling, some good tips on how to code tidily with custom exceptions and how to finally report these to the users.

Exception Design

When planning your exception handling there is one principle to follow above all others
“UI code shows errors and everything else follows the Chain-of-responsibility_pattern to deligate the exceptions”. So what does this mean in real world situations? This means that when designing your code you consider if you are working on logical code or user interface code (I hope your design means that there is a divide between these types of objects) and if your working on logical code then throw the exception back up! This means that all exceptions should end up being dealt with by UI code where they can be displayed to the user very easily. Lets consider an example using the classic Caesar cypher as an example.

Just looking at this (very rough) overview of the classes you can see that the UI is handled seperately to the logic of the encrypting of the data, which has a custom exception incase something goes wrong during encryption. When something goes wrong the logical classes deligate the responsibility of informing the user to the user interface objects that called the encrypt method. This simple change means that the only things that know about user interface details are a subset of all your classes, making proper threading of user interaction, a tidy code base and scaling the application logic much easier.

Tip: Catching Exception is not a good way of dealing with problems, often information is missed from the lower level exceptions. Using this pattern it is possible that you catch all the named exceptions at the UI and as a final case you can catch Exception itself (make sure its the last case so it doesn’t block the other methods) and you can report errors back to base etc to make sure your software is stable.

OK so following this you now know how to plan your exceptions out, making sure that they always land back to the UI to be dealt with, you also know a cool way of making sure you can even catch things you didn’t plan for! Now what do you do with the exception when you have it at the UI?

Reporting to Users

Reporting errors to users is really simple, you just need to remember one rule:

Users are not computer programmers, null pointers mean nothing to them, array index out of bounds is alien talk and they have no idea about IO errors.

You need to talk to users in their language, the language of the software (often called the domain language) so rather than saying null pointer maybe you can tell them that they need to select an item in the table, or they did not fill in a box etc. Help them to understand the problem so they can fix it themselves.

In odd cases you can’t help the user fix the problem, if a database lookup has failed maybe the user can’t do anything. Thats where error codes come in so that no error is ever completely fatal, they can find out more infromation about the problem. My personal favourite way of dealing with such issues is to to give name number pairs so that users can look up the problem and find suggestions, a lot like oracle errors handling system.

You can use an internal system to make sure that no 2 codes are the same, and provide users a simple website to lookup these codes. This means that users are never without some form of help for their problems, it also means if you look at the web stats you can find out what the most serious issues are for your users.

Summary

So there we have it, if you design your error handling properly you can make sure you always get the problems to the UI and when they do get there you have 3 options to handle them by displaying them in domain language, reporting them back to base or providing the user error codes.

If you follow these tips it will no doubt make life a lot easier for you in the long run and result in more stable software and happier users.