Coding best practices_exception handling
Download as PPTX, PDF1 like409 views
The document outlines best practices for exception handling, including never swallowing exceptions, declaring specific checked exceptions, catching specific exception subclasses rather than the base Exception class, always wrapping exceptions to preserve stack traces, either logging or rethrowing but not both, and throwing exceptions early and cleaning up afterwards. It provides 17 best practices for proper exception handling techniques.
Coding best practices_exception handling
- 1. Best Practices Exception Handling Abid Hossain Khan
- 2. Agenda ļ Advantages ļ Exception Hierarchy ļ Best Practices
- 3. Advantages ļ Represent a meaningful message to user ļ Log unhandled exception once and only once ļ Correlate exceptions with unique request id (session) in log file for high precision debugging ļ Implement powerful but extensible exception handling strategy for each tiers
- 5. Best Practice : 1 ļ Never swallow exception in catch block
- 6. Best Practice : 2 ļ Declare the specific checked exceptions that your method can throw
- 7. Best Practice : 3 ļ Do not catch the Exception class rather catch specific sub classes
- 8. Best Practice : 4 ā¢ Never catch Throwable class
- 9. Best Practice : 5 ļ Always correctly wrap the exceptions in custom exceptions so that stack trace is not lost
- 10. Best Practice : 6 ļ Either log the exception or throw it but never do the both
- 11. Best Practice : 7 ļ Never throw any exception from finally block
- 12. Best Practice : 8 ļ Always catch only those exceptions that you can actually handle
- 13. Best Practice : 9 ļ Donāt use printStackTrace() statement or similar methods
- 14. Best Practice : 10 ļ Use finally blocks instead of catch blocks if you are not going to handle exception
- 15. Best Practice : 11 ļ Throw early catch late
- 16. Best Practice : 12 ļ Always clean up after handling the exception
- 17. Best Practice : 13 ā¢ Throw only relevant exception from a method
- 18. Best Practice : 14 ļ Never use exceptions for flow control in your program
- 19. Best Practice : 15 ļ Always include all information about an exception in single log message
- 20. Best Practice : 16 ļ Use template methods for repeated try-catch
- 21. Best Practice : 17 ļ Document all exceptions in your application in javadoc
Editor's Notes
- #12: What is actor model Actor model is a universal primitive of concurrent computation in computer science. Ā How actor behaves Once an actor receives a message it can Ā It can make local decision. It can create more actors Send more messages Determine how to respond to the next message received
- #13: In java object and thread in not unified. But in actor model these two has been unified together.
- #14: Encapsulation : There is no shared state between actors Actor is access by passing message. (Message is immutable i.e. it is only pass by value) Fairness: The notation of fairness states that every actor makes progress if some computation it has to do and every message is eventually delivered to destination actor unless destination actor is not permanently disabled. Location Transparency Actual location of actor does not effect its name (processing). Actor communicated by exchanging message with other actors which can be on same CPU or on another node in cluster. It provides an abstraction to the developer to work with out worrying about physical location of actors. Mobility Mobility is defined as the ability of computation to migrate across different nodes. Mobility is important for load-balancing, fault-tolerance and reconfiguration. It is important for developing scalable applications.