Exception Handling

The do's and do not's of exception handling and throwing, specifically with Java and Spring.

Transcript

1. !!!! Exception Handling The Do’s and Do Not’s
2. The Global Exception Handler
3. You can catch unhandled exceptions thrown in Spring REST handlers in a HandlerExceptionResolver.
4. This documentation for this interface is at: http://docs.spring.io/spring/docs/3.0. x/api/org/springframework/web/servlet/Hand lerExceptionResolver.html
5. When an exception is caught, you could add code to check for another class that could this exception by returning a more specific message, defaulting to a standard message if one could not be found.
6. For example, the HttpRequestMethodNotSupportedExceptionHand ler could handle requests to an endpoint with a non-supported HTTP verb.
7. The GlobalExceptionHandler would simply proxy onwards to this class.
8. These classes would effectively catch the exception and return a pretty message to the client. They have full access to the exception.
9. A log should be made when an exception wasn’t handled by a specific class: I wasn't able to find a custom ExceptionHandler for the exception '{}' are you sure you want to handle this with the GlobalExceptionHandler? exception: {}
10. They are Exceptional
11. Do not use Exceptions for flow control. They are for exceptional circumstances, it’s all in the name.
12. public ModelAndView successfulLoginCallback(...) throws ... { try { SocialOAuthResult loginResult = login(…); } catch (RegistrationDetailsRequiredException e) { … } catch (AccountRestrictedException e) { … } }
13. Instead, use a class to encapsulate the return state (or something more appropriate).
14. public ModelAndView successfulLoginCallback(…) throws … { UserLoginResult regResult = login(…); if (regResult.isPartiallyRegistered()) { … } else if (regResult.isRestrictedAccount()) { … } }
15. If you have to use an exception, add it to the GlobalExceptionHandler - even if you don’t think it will ever go uncaught.
16. Handling Exceptions
17. Do not catch Throwable. If you find yourself needing to do this, please ask the team to weigh in - chances are, you’re doing it wrong.
19. Just catch the most relevant exceptions that you know might get thrown.
20. If you don’t preempt every possible exception, and everybody follows the rules, you’ll have only missed something truly exceptional anyway!
21. Catch exceptions just to log and then rethrow them if iffy. Try to come up with a cleaner solution.
22. Throwing Exceptions
23. Unchecked vs. checked exceptions.
24. “Use checked exceptions for conditions for which the caller can reasonably be expected to recover.”
25. “Use runtime exceptions to indicate programming errors.”
26. “Favour the use of standard exceptions.”
27. This is the end. Now go and be unexceptional. ;-)