Women in Technology

Hear us Roar



Article:
  An Exception Handling Framework for J2EE Applications
Subject:   ?
Date:   2006-01-16 23:15:21
From:   sumitaj
Response to: ?

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.

Main Topics Oldest First

Showing messages 1 through 1 of 1.

  • ?
    2006-01-17 02:17:02  Shrik [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.