Returning an Exception:

A Case for Good Error Handling

Don’t Return An Exception:

You may return “Wow” to yourself when working on code. Although I must agree I have done this, I do not think returning “Wow” would be of much help to the user. The other way you must be thinking to return information to the user is to return an error code. I still must decline. Imagine, trying to sign into a website. Instead of getting something like “Username or Password entered incorrectly” you receive “Error Code: Weasel”. I have absolutely no idea what “Weasel” means, and I am absolutely NOT going to a support page to try and find this error code and what it entails. The only way they can “Weasel” out of this mess is to return something meaningful to the user. Instead, you think it’s better to just return the exception given when the user types something wrong. I also dislike the idea of returning an exception to the user to try and find out what is wrong. Unless the user is a programmer, or my editor who has very basic knowledge of programming. If they see “NullPointerException”, the user will have no idea what it means. But if you return something like “User not found, please contact support.” Then you will have meaningful interaction between the user, and give them a place to go from there.

Handle Errors Properly:

Errors come in many different shapes and sizes. In more simple aspects of projects, someone can enter a password wrong. In bigger projects, entire systems can fail and crash whatever system you are working with. Either case, it is important to handle errors properly. If you have a really old system, you have to maintain it and can’t implement every best practice to handle errors, it is fine. Tailor everything to suit your needs best. In any case, the core thing you should always try to do, or strive for, is to log the error. This might be an exception, bad input, or something in-between. For an example: I type in my username incorrectly. I specifically made an exception called, “UserNotFoundException”. When this gets logged, I will include with it the name of the exception, where it occurred specifically, the time, what the user “accidentally” put in, IP of the user, and a session id if there is one. There are infinitely more fields you could add but this suffices for this scenario. As you can see, if a client comes to you saying they have an error, you can quickly and easily figure out where. This significantly cuts down on the time it takes to find the issue if there is one.

Show a Simple Solution:

When the user is dealing with your software, it is always best to show them responses that they can understand. What do I mean by this? Like I said earlier, it makes more sense to show them “Username or Password entered incorrectly” rather than “UsernameNotFoundException”, or even the worst offender, “Error Code: Weasel”. There is a fine line between trying to be helpful and trying to not showcase the inner workings of the software. This also deters malicious actors from trying to force their way in. If they saw “Password entered incorrectly” instead of “Username or Password entered incorrectly”, then they know the username was right. It still gets the point across to the user while purposely leaving out information.

Remember, even if you can’t implement every best practice for your site when implementing error handling; just logging it is one of the best things you can do. Whether it’s an error, exception, or anything in-between, remember to log your errors and keep on coding.

By partnering with GoodJava, you can take your information to the next level. For articles like this, read our other wonderful blogs or visit our Contact Us Page and Get Started.