INTEGU uses cookies to personalize your experience and provide traceability for affiliate links. By using the website, you agree to these terms and conditions. To learn more see the privacy policy page.
Exceptions
Java Best Practices Series
Menu
Exceptions
69. Exceptions Only For Exceptional Scenarios
Exceptions are a way of causing the system to quickly alert the system of some unexpected scenario. However, some people might start using exceptions as a functionality of the system and start relying on the to convey acceptable scenarios.
Utilizing exceptions like this is not recommendable, since it blurs the lines between acceptable and unacceptable behaviour.
Meanwhile the JVM does not perform the same kind of performance optimization for exceptions, as alternatives.
70. Checked VS. Unchecked Exceptions
Checked exceptions require methods to handle them through either a try-catch or propagating the exception out towards the method calls origin. This thereby requires the developer to confront the exception and create a scenario in which the system will recover.
Check: System should be expected to recover.
Unchecked: System should be expected to shut down. (programming error)
71. Avoid Unnecessary Checked Exceptions
Checked exceptions require the developer to handle the scenario in which the exception is thrown. However, sometimes methods which can throw checked exceptions have multiple variations of logic routes. This means that they might never reach the part in which the method is thrown. Regardless of this, any call to this method, still require that the exception is handled.
If possible, it should therefore be attempted to make alternative methods or logic paths, which does not require checked exceptions.
72. Reuse Standard Exceptions
Similar to item 59, it is worth reusing code build by others. When it comes to exceptions, this means reusing standard exceptions like IllegalStateException, IllegalArgumentException etc.
These exceptions are well-known and conveys an easily understood concept to other developers.
The alternative of creating new exceptions can quickly end up making more confusion, than clarity.
73. Throw Exceptions According To The Abstraction
Whenever transferring a checked exception out through the system, it might be necessary to translate it to a new type of exception when getting into a new abstraction level.
On DAO-level exceptions might relate to concepts such as for example “rollback”.
However, when that exception then reaches the higher level of the server,it might be worth translating it to an exception related to the concept which caused the error.
74. Document Exceptions
Whenever a method can throw a checked exception it is recommendable to use javadoc (@throws) to explain under exactly which conditions this exception is expected to be thrown.
This way, the next developer will quickly be able to determine, whether they should make any special considerations, when altering the code around the exceptions.
75. Provide Relevant Information When Failing
When an exception is thrown, causing the system to crash, it is valuable to know all related parameters, which could have caused the failure.
It should therefore be considered to include these parameters within the exception.
For custom made exceptions, this could be achieved by making constructors, which required these parameters to be given.
76. Failure Should Never Cause Objects To Change
Whenever a method fails, it should be expected to return the object in the same state as before the method was invoked. Alterations made to any object within the flow of a failing method could potentially set the system up for continues failure.
One way of ensuring that objects remain the same, is by using immutable objects.
77. Don’t Ignore Exceptions
Sometimes we call a method, which requires us to handle a potential exception. Some developers might not want to deal with these type of external exceptions, and simple surround it with a try-catch. Doing nothing to handle the exception in the catch block.
However, this behaviour defeats the purpose of the exception and sets the system up for failure. Any checked exception is expected to be considered and handled.
If you never end up in a scenario where you are certain that a given exception can never be thrown, you should aim to build the system so that you will therefore not have to handle it.
It should be a last resort to ignore the exception. However, if done, it needs to be accommodated with a detailed comment, explaining why it is ignored.
Recommended Reading
Books
- Effective Java – Joshua Bloch – Amazon (Affliate Link)
About
Hi, I'm the Author
My name is Daniel H. Jacobsen and I’m a dedicated and highly motivated software developer with a masters engineering degree within the field of ICT.
I have through many years of constantly learning and adapting to new challenges, gained a well-rounded understanding of what it takes to stay up to date with new technologies, tools and utilities.
The purpose of this blog is to share both my learnings and knowledge with other likeminded developers as well as illustrating how these topics can be taught in a different and alternative manner.
If you like the idea of that, I would encourage you to sign up for the newsletter.
Cheers! 🍺
