What do you think of this exception-handling approach?
You must be logged in to the O'Reilly Network to post a talkback.

Showing messages 1 through 30 of 30.

• Problem in integrating the code.
  2008-05-27 07:36:41  rohit566 [Reply | View]
  
  
  Hi.
  I have a Model class, contain a method insert() for inserting data into database.and it throws Exception.Now i am calling that insert() in my controller.so i have to handle that exceptions in my controller class.But problem is where do i need to place the code(Exception handling framework code) to handle the exceptions. in that given example i found 2 action classes. storeAction and BaseAppDispatchAction.which class code is usefull for me.? I am new to this framework.plz help me out.

• nice article
  2007-08-07 21:36:57  daringtakers [Reply | View]
  
  
  Very useful article.
  Handling exception efficiently is realii a difficult thing. a gud articles to lean handling exception efficiently.
  
  http://www.jyog.com
  
  
  

• Request Processor
  2007-02-23 12:40:45  scranthdaddy [Reply | View]
  
  
  Would it make sense to do the functionality of BaseAction in the RequestProcessor (FrontController pattern)?

• logging original stack trace
  2007-02-07 12:35:23  scranthdaddy [Reply | View]
  
  
  I have a rather newbie question but hopefully you can help advise.
  
  If my existing web application logs the stack trace to the filesystem/database, how can I keep that functionality and fit that into your framework? Logging of the original exception stack trace is important to me for debugging the source problem and if I wrap everything into a BaseAppException sub class then I would not be able to see the stack trace.
• logging original stack trace
  2007-02-07 20:55:33  Shrik [Reply | View]
  
  
  Wrapping the root exception with BaseAppException will not the stack-trace of original cause if you are working in JDK 1.4+ environment. However, for older JDK versions, there is a problem in keeping original stacktrace intact. <b/> In that case you need to modify BaseAppException for root-cause stacktrace implementation. You can take a look on NestedCheckedException implementation in Spring framework as a reference for the same.
• logging original stack trace
  2007-02-07 20:53:14  Shrik [Reply | View]
  
  
  Oops. A typo mistake :-(. Here it reads better now :-)
  
  You will not lose the original stacktrace by wrapping the cause with BaseAppException in JDK 1.4+ environment.
  

• making aop based
  2006-10-08 19:05:03  aoplearner [Reply | View]
  
  
  Your article is very useful. I am wondering if your framework fits into AOP based exception handling(I am new to AOP). Please let me know your views and pointers to the related articles on web.
  Thanks in advance.

• making aop based
  2006-10-08 19:04:59  aoplearner [Reply | View]
  
  
  Your article is very useful. I am wondering if your framework fits into AOP based exception handling(I am new to AOP). Please let me know your views and pointers to the related articles on web.
  Thanks in advance.

• Exception handling framework
  2006-04-13 06:38:56  angryguy [Reply | View]
  
  
  Does anyone have a concrete example of this exceptin handling framework in action. Even a simple application that was functional would be extremely helpfull. If so please post it here.
• Exception handling framework
  2006-04-13 08:52:02  Shrik [Reply | View]
  
  
  It's not possible to post an application in this forum for obvious reasons. An example of a Struts based Action implementation has already been provided. Also an example of using IExceptionHandler for a stand-alone program is given. In case you have any specific question about the framework, feel free to shoot.

• useful ideas
  2006-02-12 13:52:08  dario_ [Reply | View]
  
  
  I deal daily with a large team of developers, each of one uses exceptions in a very personal and inconsistent way. I get all the time the same set of reasons as I read in the previous posts, and I notice in those reasons a lack of understanding of the problem (even a denial of the problem)
  Your ideas are a starting point to a standardization strategy I'm looking for, and I like them. But I still feel they need some improvement, as throwing BaseAppException in all the methods has some of the drawbacks of always throwing java.langn.Exception.
  
• useful ideas
  2006-02-12 18:29:58  Shrik [Reply | View]
  
  
  Here is a catch. Please note that we are not throwing BaseAppException from the methods but its derived classes. In other words we are not throwing just java.lang.Exception but its so many derived classes. Definitely the throws clause just contains BaseAppException but client (ExceptionHandler) will get derived exception classes only, based on the principle of polymorphism. You need to see it from a perspective why do you use a base class in a method signature instead of its derived concrete classes in case you want to use polymorphism. You'll find an answer now on why we just throw BaseAppException.
• useful ideas
  2006-02-13 02:38:01  dario_ [Reply | View]
  
  
  I see your point and I understand code will actualy throw derived exceptions, and that by itself is good enough. What I also see is that if I just make a find and replace of BaseAppException for Exception, the design and architecture of the app stay the same, so the need for the BaseAppException is only to differentiate the exceptions that come from my services from the ones that come from third party services and J2SE itself. Not saying that that goal is not enough, just that I feel that all my methods are defined as if they were throwing 'Exception'. May be i'm missing something, but on the other hand, I don't think there's a perfect solution, so this one is good enough for me if I add another rule: if an exception in a method depends on the 'implementation' of the method and not on the concept of the method, wrap it in RuntimeExceptions. This way, if for example I change a File based implementation for a JDBC based implementation, the caller sees no change. After all, the caller has no idea if the implementation, so why would it need to catch the implementation dependent exception?
• useful ideas
  2006-02-13 03:51:31  Shrik [Reply | View]
  
  
  What I also see is that if I just make a find and replace of BaseAppException for Exception, the design and architecture of the app stay the same
  
  I am afraid that design and architecture will not remain same. BaseAppException explicitely deals with checked exceptions for an application. When you talk about using Exception, it's a base class for RuntimeException (unchecked exception) as well as other checked exceptions. By using the abstraction of BaseAppException we are clearly mentioning that framework will handle all checked exceptions which derive from BaseAppException. It's definitely not a contract for RuntimeExceptionS.
  
  This way, if for example I change a File based implementation for a JDBC based implementation, the caller sees no change.
  
  In my view you can throw checked exceptions too from data-access layer if root cause of them is recoverable. For instance if there is Unique Constraint Violation or StaleData problem while updating a record, you'd still like to show a friendly message to the end user as they are recoverable and user can try again. However important point here to note is that exception thrown shouldn't be third party dependendent. Which means that even if you are using JDBC or Hibernate as data-access implementation, exceptions thrown from the data-access interface should be independent from these implementations or in other words should not be dependent on JDBC or Hibernate. These exceptions will again be inherited from the derived class (say DBException) of BaseAppException and will be meaningful exceptions wrapping the root cause. Based on error code you get from SQLException or HibernateException, you can create your own user-friendly exceptions like UniqueConstraintViolationException or StaleDataException which will be recoverable for the application. These exceptions will defintely contain the root cause for logging purposes. If you check the exception handling in Spring framework, you will find similar concept. Only difference is that in Spring every exception is unchecked exception which is not the case for this framework.
  
  Again I would like to remind you that the basis of creating RuntimeException is -- whether the exception in question is recoverable or not. If it's fatal and end-user can't do anything with it, it should be a RuntimeException otherwise should be a checked exeption (derived class of BaseAppException) only.

• Bad code example
  2006-01-16 23:40:21  sumitaj [Reply | View]
  
  
  You have provided a good approach for handling exception for a J2EE app . But the code example is not good:
  
...
CustomerDTO custDTO = null;
try{
//Get customer details
//from local database
customerDAO.getCustomerFromLocalDB();
}catch(CustomerNotActiveException){
...
return customerDAO
.activateCustomerDetails();
}
}

  
  1.Here you are using exceptions for controlling program flow which is a bad programming practice.
  
  2. You add two exceptions to your method signature for handling different error conditions which is a bad approach if the method throws, lets say 5 exceptions.
  A better approach would be to add a variable of throwable type to your baseException class and assign the exception to this var.
  In the client code you can retrieve this exception and do custom processing using instanceOf .
  

  Like this:

  
  
CustomerDAO method:
//throws BaseAppException
public void abc()
throws BaseAppException{
.....
// if not details found
throw new BaseAppException(new CustomerNotActiveException(
"Customer is not active"));
}

Client method:

//catch CustomerNotActiveException

public void xyz()
{
...

try{
...
}catch(BaseAppException ex){
...

if (ex().getCause() instanceof CustomerNotActiveException) {.. }
}

  
• Bad code example
  2006-01-16 23:58:26  Shrik [Reply | View]
  
  
  Using instanceof operator (please refer to Avoid instanceof operator (http://www.javapractices.com/Topic31.cjp) ) itself is a bad practice and you still need to use exception for program flow. In case exception needs to be dealt at any other place other than the Controller itself as mentioned in the example, it's better to make contract clear to the client instead of embedding the cause in the BaseAppException and checking its type. This kind of situation (where you need to handle the exception other than at Controller end) is rare in normal J2EE applications and for those situations I don't think there is any harm in putting the exception explicitely in the throws clause.

• ?
  2006-01-13 06:04:32  namakemono [Reply | View]
  
  
  just use struts declarative exception handling, and either write your own exception handler or use the default one (making sure your log4j.properties log level is set to debug for the exceptionhandler class).
  
  most of the advice in this article seems totally unnecessary due to cluelessness about existing facilities in struts for exception-handling.
  
• ?
  2006-01-13 09:13:37  Shrik [Reply | View]
  
  
  There are reasons why we didn't (rather couldn't) use the Struts declaritive exception handling. First of all, as already mentioned in the article, discussed strategy can be applied anywhere irrespective of whether you are using Struts or any other presentation framework. It can be even used in standalone Java programs also without any changes. So, the target was to have an exception handling framework which could be used anywhere seamlessly. Other reason leads us to understand where to use and where not to use the Struts declaritive exception handling.
  
  Most of the time we would like to generate an ActionError and display it to the
  user instead of displaying an error page. Let us take an example:
  

  
  
  <struts-config>
  
     <global-exceptions>
  
       <exception
  
          key="xmlparse.error"
  
             type="org.expframework.exception.XmlParseException"
  
             path="/error.jsp"/>
  
     </global-exceptions>
  
  </struts-config>
  
  
  
  

  
  When XmlParseException is thrown, the user sees error.jsp. This makes sense since XmlParseException is a system exception and the only thing you can do is to ask the user to start all over again. However, it may not make sense to do so when NoRecordFoundException is thrown since this is an application exception from which the user has a recovery path. A better option is to show this as an ActionError and give the user a chance to change search criteria. For situations like this, you have to resort to programmatic
  exception handling. And that's what we are doing in the article.
  
  In this article we also discussed about context sensitive exceptions. We can have multiple messages for the same exception based on the context specified. I don't think if you could achieve the same using Struts based declaritive exception handling.
• ?
  2006-01-16 23:15:21  sumitaj [Reply | View]
  
  
  However, it may not make sense to do so when NoRecordFoundException is thrown since this is an application exception from which the user has a recovery path. A better option is to show this as an ActionError and give the user a chance to change search criteria. For situations like this, you have to resort to programmatic
  exception handling
  
  This emphasizes your cluelessness even more.
  Check out the local exception tags.They
  provide a much cleaner way to implement the same.
  
  
  I don't think if you could achieve the same using Struts based declaritive exception handling.
  
  
  Struts provides a much better way for localizing messages. Simply add an error code to your BaseException and print the localized message by creating your own ExceptionHandler which extends the struts errorhandler.Map your base exception to
  the custom error handler.
• ?
  2006-01-17 02:17:02  Shrik [Reply | View]
  
  
  This emphasizes your cluelessness even more. Check out the local exception tags.They provide a much cleaner way to implement the same.
  
  I don't think local exception tags have anything to do with the situation I described above. They are just meant for handling the exceptions generated by the particular Action class defined in the Action mapping as oppposed to all Action classes in case of global exception tags. The problem is rather simple. We want to show an error message on the Search screen itself for NoRecordFoundException or EmployeeNotFoundException case instead of showing a different error page. For a single exception, there might be many error messages (based on the context) and many ActionForward mapping for different Action methods. Unless you send this information somehow to the custom ExceptionHandler, it will pick single error code and single ActionForward as mapped in the struts-config.xml for that particular exception which is not what we desire. So to pass this information to the ExceptionHandler, either you need to put that information in HttpServletRequest/ThreadLocal object or put it in the exception itself. If you intercept the exception in the Action and then put that information in the exception, it'll defeat the purpose of declaritive exception handling. And the earlier approach we are already using in this article.
  
  I would like to mention yet again that the basic USP of this article is to have an exception handling approach which could be used in any Java based application irrespective of what third party framework you are using. Another important point is to avoid boiller-plate code as much as possible. As discussed earlier also, the approach is not limited to J2EE based applications only, it can be used even in a normal standalone Java program also. The mentioned approach works for Struts based applications too as it does for any other applications.
  
  Struts provides a much better way for localizing messages. Simply add an error code to your BaseException and print the localized message by creating your own ExceptionHandler which extends the struts errorhandler.Map your base exception to the custom error handler.
  
  You can do that but there are a few problems. The context needs to be added at Struts Action method level and should not be added at business tier level as error messages are decided based on the screen or UI you are going to display. It means that you need to catch (have try-catch blocks again) BaseAppException at Struts method level and add context over there and then rethrow. We want to avoid it and avoid using boiller-plate code anymore.

• Missing Important New Approaches
  2006-01-12 23:51:16  thomasvan de velde [Reply | View]
  
  
  I am missing a discussion on the role AOP plays in exception handling. Exception softwening, after throwing advice are IMO more interesting techno's for exception handling than Struts.
• thsi approach not fit in SOA Based application
  2007-10-09 02:58:14  munira.shaikh [Reply | View]
  
  
  If in SOA based Application we need to handle exceptions at each layer do reply how to proceed with it
• thsi approach not fit in SOA Based application
  2007-10-09 02:58:11  munira.shaikh [Reply | View]
  
  
  If in SOA based Application we need to handle exceptions at each layer do reply how to proceed with it
• thsi approach not fit in SOA Based application
  2007-10-09 02:57:55  munira.shaikh [Reply | View]
  
  
  If in SOA based Application we need to handle exceptions at each layer do reply hwo to proceed with it
• Missing Important New Approaches
  2006-01-18 06:01:59  Shrik [Reply | View]
  
  
  The focus of the article is to have a detailed discussion on a new exception handling approach. Because of already broad canvas, it doesn't talk about other technos. Many of the enterprises may not want to go to AOP way because of enhanced complexity and sheer difficulty in debugging. You do not need a hammer, if the same problem could be resolved in object oriented way.

• ignorant
  2006-01-12 11:04:53  dbwduh [Reply | View]
  
  
  
  >"Fortunately, the Java APIs have a category of exceptions called unchecked exceptions, which you are not forced to catch."
  
  Java does not force you to catch anything.
  A simple throws clause will do.
  
  I am not able to read any more of this article - after reading this (ignorant) sentence.
• ignorant
  2006-01-12 19:35:29  Shrik [Reply | View]
  
  
  I am not sure if you have seen the context in which I am saying it. Just before this line I am talking about checked exceptions which you either need to catch or throw (using yet another throws clause)again. And that may be a chain reaction if the exception needs to be dealt at Controller level only. Unchecked exceptions come for the rescue there. But where to use them and where not has been described in the article.
• ignorant
  2006-01-12 20:31:53  Shrik [Reply | View]
  
  
  In the last post I meant putting yet another exception in the throws clause instead of using yet another throws clause. Sorry about that.
  
  Thanks,
  -ShriKant
• source code
  2006-05-17 23:54:40  doubts12345 [Reply | View]
  
  
  where can i get the source code of Exception handling framework.....
• source code
  2006-05-18 00:08:19  Shrik [Reply | View]
  
  
  Please check the Resources section of the article and download "Sample Code".