Training material exceptions v1
Download as PPTX, PDF0 likes15,906 views
This document provides an overview of exception handling in Java. It defines exceptions as events that disrupt normal program flow and discusses different types of exceptions including checked exceptions that must be handled and unchecked exceptions that do not require handling. It also covers how to declare, throw, and catch exceptions in code as well as best practices for logging exceptions. Finally, it summarizes exception handling in WebSphere Commerce, including application-specific and system exceptions.
Training material exceptions v1
- 1. Training Material Exception Handling By Shinu Suresh
- 2. Agenda • Exceptions • Exceptions by Nature • Types of Exceptions • Handling Exceptions • Handling Exceptions in Websphere Commerce
- 3. Exceptions “An exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program’s instructions” • Exceptional conditions are not necessarily rare
- 4. Nature of Exceptions • Exceptions due to programming errors Exceptions are generated due to programming errors (e.g., NullPointerException and IllegalArgumentException). The client code usually cannot do anything about programming errors. • Exceptions due to client code errors Client code attempts something not allowed by the API, and thereby violates its contract. • Exceptions due to resource failures Exceptions that get generated when resources fail. For example: network connection fails. • The parameters given to the method are not well defined (i.e. are wrong / null where they must not be)
- 5. Cont.. • The "constellation" of the parameter values are not expected in the given way by the method (because if parameter "a" has a certain value, "b" must not be of another certain value) • 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.) • 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) • The method relies on external resources (i.e. file system, database etc.) which are not available at the moment they are needed
- 6. Types of Exception • 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. • 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.
- 8. Java.lang.Error • 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. • 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. • Java Language Specification advises against throwing errors. It is intended that errors be thrown only by the Java runtime.
- 9. Checked vs Unchecked Client reaction when exception happens Exception Type Client code cannot do anything Make it an UnChecked Exception Client code will take some useful recovery actions based on information in exception Make it Checked Exception If you are throwing an exception to indicate an improper use of your class, you are signalling a software bug Descend from RuntimeException which will make it UnChecked 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 Make it Checked Exception 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.
- 10. Handling Exceptions • Declaring Exception Method should declare the exception it throws in its signature UnChecked exceptions need not be thrown • Throwing an Exception When program encounters an abnormal operation, the method containing the erroneous statement create an appropriate Exception object and throw it public void methodD() throws XxxException, YyyException { // method's signature // method body throw XxxException and YyyException } public void methodD() throws XxxException, YyyException { // method's signature // method's body ... ... // XxxException occurs if ( ... ) throw new XxxException(...); // construct an XxxException object and throw to JRE ... // YyyException occurs if ( ... ) throw new YyyException(...); // construct an YyyException object and throw to JRE ... }
- 11. Handling Exceptions Cont. • Catching an Exception When a method throws an exception, the Java runtime searches backward through the call stack for a matching exception handler. Each exception handler can handle one particular class of exception. If no exception handler is found in the call stack, the program terminates. public void methodC() { // no exception declared ... try { ... // uses methodD() which declares XxxException & YyyException methodD(); ... } catch (XxxException ex) { // Exception handler for XxxException ... } catch (YyyException ex} { // Exception handler for YyyException ... } finally { // optional // These codes always run, used for cleaning up } ... }
- 12. Handling Exceptions in Websphere Commerce • Well defined and simple to use in customized code • Supports multicultural stores • Tightly integrated with Logging system Two Types of Exceptions primarily Exception ECApplicationException ECSystemException
- 13. Exception Flow Solution Controller invokes Controller Command Command throws exception (ECApplicationException or ECSystemException) Struts determines error global forward and invoke specified error view
- 14. • ECApplicationException This exception is thrown if the error is related to user input and will always fail. For example, when a user enters an invalid parameter, an ECApplicationException is thrown. When this exception is thrown, the solution controller does not retry the command, even if it is specified as a retriable command. • ECSystemException This exception is thrown if a runtime exception or a WebSphere Commerce configuration error is detected. Examples of this type of exception include 1. Create exceptions 2. Remote Exception 3. EJB Exceptions When this type of exception is thrown, the solution controller retries the command if the command is retriable and the exception was caused by either a database deadlock or database rollback.
- 15. Points to remember • Exceptions should generally be allowed to propagate up the stack ultimately resulting in a roll-back and error response. This might mean catching and re-throwing exceptions. If this is the case, exceptions should always include the original exception so that the root cause is known. An example would be a retry in the case of a network failure etc. • If the operation can be retried then it should be. • Exceptions should not be used to implement business logic (there is a performance overhead with throwing an exception) • Exceptions should never just be caught and ignored • Exception handling framework will be developed for the project wherein all Exceptions will be either XApplicationException or XSystemException
- 16. Example try{ //--------------------- //<Business logic> //--------------------- }catch(ECApplicationException e){ throw new XApplicationException(exp.getECMessage(),this.CLASS_NAME,METHOD_NAME, LoggerIdentifier.COMPONENT_CATALOG); } catch(ECSystemException e){ throw new XSystemException(exp.getECMessage(),this.CLASS_NAME,METHOD_NAME, LoggerIdentifier.COMPONENT_CATALOG); } 1. Produces a stack trace for any exception caught. 2. Parameters are logged at the time of the exception. 3. ECExceptions and its subclasses are logged only once.
- 17. Exception Logging • Uses WCS Logging framework • Entering and exiting method logging must be provided • Use entering () and exiting () methods on the Logger and not log (Level.INFO, "Entering method xxx..."); • Different log levels are there for a reason. So be careful what you will log using INFO level. Probably no one (except you) is interested in list of parameters and values going to your direct SQL query or details about a person. This should be really using FINE or lower. • Log a meaningful message. Parameter=value type of message doesn't count as meaningful • Logging liberally with FINE which will help in debugging issues in LIVE
- 18. JSP And Error handling • Use StoreErrorDataBean to display store specific error messages in JSP page The databean provides getter methods to • Retrieve the store error key, <ECMessageKey>.<Error Code> • Retrieve the error message parameters, that is, the substitution parameters used in the error messages StoreDataBean rely on existence of store error message properties file. Eg:- storeErrorMessages_ locale.properties
- 19. Using StoreDataBean in JSP <wcbase:useBean id="storeError“ classname="com.ibm.commerce.common.beans.StoreErrorDataBean“ scope="page"> <c:set target="${storeError}" property="resourceBundleName“ value="${sdb.jspStoreDir}/storeErrorMessages" /> </wcbase:useBean> <c:if test="${!empty storeError.key}"> <c:set var="errorMessage" value="${storeError.message}" /> </c:if> //storeErrorMessages_ locale.properties _ERR_CMD_INVALID_PARAM.2020 = Type an e-mail address in the E-mail address field.
- 21. Payment Exceptions cont • EDPException The root exception of the Payment rules engine • PluginException The root exception of the payments plug-in. Throw this exception in case of exceptional scenarios or if you don’t find any suitable exceptions in the already existing ones For more reference http://pic.dhe.ibm.com/infocenter/wchelp/v7r0m0/topic/com.ibm.commerce.paymen ts.events.doc/refs/rppppcspec.htm?resultof=%22%70%61%79%6d%65%6e%74%22%2 0%22%65%72%72%6f%72%22%20%22%68%61%6e%64%6c%69%6e%67%22%20%22 %68%61%6e%64%6c%22%20
- 22. Thank You
Editor's Notes
- #21: For each kind of PluginException, there is a corresponding type of EDPException. For example, com.ibm.commerce.payments.plugin.InvalidDataException is a PluginException, and com.ibm.commerce.edp.api.InvalidDataException is its corresponding EDPException. InvalidDataException – If Shopper submits invalid payment