Exception Handling

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.
18. None

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. ;-)