filmov
tv
Java Clean Code Tutorial #6 - Exception Handling - Prefer Runtime Exceptions
Показать описание
Exception handling is a critical part of software and java developers often are unaware of the choice of base exceptions, RuntimeException and Exception.
It is NOT bad practise to use extend RuntimeException, just have a look at SpringFramework or most open source projects. Everything has its place.
When your method throws checked exceptions, you force the client to handle the exception even when they don’t know how to. This can result in human error bugs such as:
LOG/SWALLOW – Resulting in Errors / unpredictable behaviour.
LOG/SWALLOW/THROW New Exception without a cause – Resulting in lost ‘cause’ stack traces which are hard to find in logs. Especially if they have a different correlation ID.
LOG/Throw new exception. Resulting in lost ‘cause’. This cause can never be found as it was never logged, this makes it extremely hard for developers to reason on what actually caused the failure.
If you do not perform a try/catch then you need to couple the client API methods with the exception that was thrown from the method. Just think if you need to propagate it 3 layers up the stack? This can get messy!
I believe that developers should utilise and extend RuntimeException to allow flexibility in their API and also reduce clutter. With RuntimeExceptions you now have the ability to catch your exception where you can handle it and not couple the stack with ‘throws X declarations or try/catch/rethrow’.
When dealing with RuntimeExceptions I also recommend a ‘catch all’ at the base of the application to stop any exceptions propagating to the client/UI or out of the JVM. This is also good security practise as some exceptions may leak sensitive data.
Software is written once and read hundreds of times. So let’s make our fellow developers life easier.
Why clean code?
Simple. Clean code allows us to confidently make changes and deliver more features quickly to our customers.
Don’t forget to subscribe for your regular dose of Java Tutorials!
STOP THE ROT.
Till episode 7,
Philip
Episode 6 of the free Java Clean Code Training Series.
It is NOT bad practise to use extend RuntimeException, just have a look at SpringFramework or most open source projects. Everything has its place.
When your method throws checked exceptions, you force the client to handle the exception even when they don’t know how to. This can result in human error bugs such as:
LOG/SWALLOW – Resulting in Errors / unpredictable behaviour.
LOG/SWALLOW/THROW New Exception without a cause – Resulting in lost ‘cause’ stack traces which are hard to find in logs. Especially if they have a different correlation ID.
LOG/Throw new exception. Resulting in lost ‘cause’. This cause can never be found as it was never logged, this makes it extremely hard for developers to reason on what actually caused the failure.
If you do not perform a try/catch then you need to couple the client API methods with the exception that was thrown from the method. Just think if you need to propagate it 3 layers up the stack? This can get messy!
I believe that developers should utilise and extend RuntimeException to allow flexibility in their API and also reduce clutter. With RuntimeExceptions you now have the ability to catch your exception where you can handle it and not couple the stack with ‘throws X declarations or try/catch/rethrow’.
When dealing with RuntimeExceptions I also recommend a ‘catch all’ at the base of the application to stop any exceptions propagating to the client/UI or out of the JVM. This is also good security practise as some exceptions may leak sensitive data.
Software is written once and read hundreds of times. So let’s make our fellow developers life easier.
Why clean code?
Simple. Clean code allows us to confidently make changes and deliver more features quickly to our customers.
Don’t forget to subscribe for your regular dose of Java Tutorials!
STOP THE ROT.
Till episode 7,
Philip
Episode 6 of the free Java Clean Code Training Series.
Комментарии