Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Exception Handling Java


Published on

An easy way to understand the exceptions & error in java

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Exception Handling Java

  1. 1. Effective use of exception handling in Java Ankit
  2. 2. Overview <ul><li>What is an exception ? </li></ul><ul><li>Nature of exceptions </li></ul><ul><li>Conditions where exception could be generated </li></ul><ul><li>Types of exceptions in Java </li></ul><ul><li>Checked Vs Unchecked exceptions </li></ul><ul><li>Contingency & Fault </li></ul>
  3. 3. What is exception ? <ul><li>An abnormal condition, therefore, would be any condition that wouldn't reasonably be expected as part of the &quot;normal functioning&quot; of a method. </li></ul><ul><li>Exceptional conditions are not necessarily rare. </li></ul>
  4. 4. The Nature of exception <ul><li>Exceptions due to programming errors </li></ul><ul><li>Exceptions are generated due to programming errors (e.g., NullPointerException and IllegalArgumentException). The client code usually cannot do anything about programming errors. </li></ul><ul><li>Exceptions due to client code errors </li></ul><ul><li>Client code attempts something not allowed by the API, and thereby violates its contract. </li></ul><ul><li>Exceptions due to resource failures </li></ul><ul><li>Exceptions that get generated when resources fail. For example: network connection fails. </li></ul>
  5. 5. Conditions where Exception could be generated. <ul><li>The parameters given to the method are not well defined (i.e. are wrong / null where they must not be) </li></ul><ul><li>The &quot; constellation &quot; of the parameter values are not expected in the given way by the method (because if parameter &quot;a&quot; has a certain value, &quot;b&quot; must not be of another certain value) </li></ul><ul><li>The caller of the method simply calls it in an improper way (i.e. the environmental conditions are not correct, needed resources are not allocated yet etc.) </li></ul>
  6. 6. Cont… <ul><li>The method allocates external resources (i.e. open connections, file handles etc.) and does not free them (thus leading to an invalid internal state of the program, the operating system or other components like databases) </li></ul><ul><li>The method relies on external resources (i.e. file system, database etc.) which are not available at the moment they are needed </li></ul>
  7. 7. Types of Exceptions in Java <ul><li>Checked exceptions: Exceptions that inherit from the Exception class are checked exceptions. Client code has to handle the checked exceptions thrown by the API, either in a catch clause or by forwarding it outward with the throws clause. </li></ul><ul><li>Unchecked exceptions: RuntimeException also extends from Exception. However, all of the exceptions that inherit from RuntimeException get special treatment. There is no requirement for the client code to deal with them, and hence they are called unchecked exceptions. </li></ul>
  8. 10. What is java.lang.Error ? <ul><li>Errors (members of the Error family) are usually thrown for more serious problems, such as OutOfMemoryError, that may not be so easy to handle. In general, code you write should throw only exceptions, not errors. Errors are usually thrown by the methods of the Java API, or by the Java virtual machine itself. </li></ul>
  9. 12. Why against throwing “Error” ? <ul><li>Errors usually signal abnormal conditions that you wouldn't want a program to handle. Problems with linking, such as NoClassDefFoundError, or memory, such as StackOverflowError, could happen just about anywhere in a program. In the rare cases in which they happen, it is usually reasonable that the thread terminate. </li></ul><ul><li>Java Language Specification advises against throwing errors. It is intended that errors be thrown only by the Java runtime. </li></ul>
  10. 13. Checked vs. Unchecked exceptions <ul><li>Ask yourself </li></ul><ul><li>&quot;What action can the client code take when the exception occurs?&quot; </li></ul>
  11. 14. Make it a checked exception Client code will take some useful recovery action based on information in exception Make it an unchecked exception Client code cannot do anything Exception type Client's reaction when exception happens
  12. 15. Cont… <ul><li>If you are throwing an exception to indicate an improper use of your class, you are signalling a software bug. The class of exception you throw probably should descend from RuntimeException, which will make it unchecked. </li></ul><ul><li>If you are throwing an exception to indicate not a software bug but an abnormal condition that client programmers should deal with every time they use your method, your exception should be checked . </li></ul>
  13. 16. throws Vs try-catch <ul><li>If you feel that a method doesn't know how to handle a particular error, you can throw an exception from the method and let someone else deal with it. If you throw a &quot;checked&quot; exception, you enlist the help of the Java compiler to force client programmers to deal with the potential exception, either by catching it or declaring it in the throws clause of their methods. </li></ul>
  14. 17. Another Approach to decide whether to use checked exception or unchecked. <ul><li>One design approach often discussed in the context of object-oriented programming is the Design by Contract approach. This approach to software design says that a method represents a contract between the client (the caller of the method) and the class that declares the method. The contract includes preconditions that the client must fulfil and postconditions that the method itself must fulfil. </li></ul>
  15. 18. What information does java.lang.Exception contain <ul><li>The type of exception -- the exception class </li></ul><ul><li>Where the exception occurred -- the stack trace </li></ul><ul><li>Context and explanatory information -- the error message, and other state information </li></ul>
  16. 19. An approach to design your application
  17. 20. Contingency & Fault <ul><li>Contingency </li></ul><ul><li>An expected condition demanding an alternative response from a method that can be expressed in terms of the method's intended purpose. The caller of the method expects these kinds of conditions and has a strategy for coping with them. </li></ul><ul><li>Fault </li></ul><ul><li>An unplanned condition that prevents a method from achieving its intended purpose that cannot be described without reference to the method's internal implementation. </li></ul>
  18. 21. Mapping to java exception An unchecked exception A checked exception Best Mapping Programming bugs, hardware malfunctions, configuration mistakes, missing files, unavailable servers Alternative return modes Examples The people who need to fix the problem The upstream code that invokes the method Who cares about it Never rarely Is expected to happen A nasty surprise A part of the design Is considered to be Fault Contingency Condition
  19. 22. Goals of a successful fault handling framework <ul><li>Minimize code clutter </li></ul><ul><li>Alert the right person </li></ul><ul><li>Exit the activity gracefully </li></ul>
  20. 23. Establish a “Fault Barrier” <ul><li>The fault barrier resides logically toward the top of the call stack where it stops the upward propagation of an exception before default action is triggered. </li></ul><ul><li>The first responsibility of a fault barrier component is to record the information contained in the fault exception for future action. </li></ul><ul><li>The next responsibility of a fault barrier is to close out the operation in a controlled manner </li></ul>
  21. 25. References <ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul>
  22. 26. <ul><li>Thank you </li></ul>