Exception handling in Struts 2 and Hibernate

Question

Suppose that we have developed a website in Struts 2, Hibernate, MySQL and we have added few try/catch blocks here are there which encloses database calls via Hibernate.

My question is:

1. Inside the catch block l am sending appropriate message to a logger. Here we can't use System.out.println as its a webpage, what else can be done to alert the user about exception?

2. As a part of testing I changed the hibernate.cfg.xml and input wrong database password so as to simulate the database crash scenario.

as I expected It threw error:

    javax.servlet.ServletException: Filter execution threw an exception

    java.lang.NoClassDefFoundError: com_cenqua_clover/CoverageRecorder
    my.com.employee.<init>(employee.java:29)
    com.action.employeeAction.<init>(employeeAction.java:23)
    sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
    sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
    java.lang.reflect.Constructor.newInstance(Constructor.java:513)
    java.lang.Class.newInstance0(Class.java:355)
    java.lang.Class.newInstance(Class.java:308)
    com.opensymphony.xwork2.ObjectFactory.buildBean(ObjectFactory.java:119)
    com.opensymphony.xwork2.ObjectFactory.buildBean(ObjectFactory.java:150)
    com.opensymphony.xwork2.ObjectFactory.buildBean(ObjectFactory.java:139)
    com.opensymphony.xwork2.ObjectFactory.buildAction(ObjectFactory.java:109)
    com.opensymphony.xwork2.DefaultActionInvocation.createAction(DefaultActionInvocation.java:288)
    com.opensymphony.xwork2.DefaultActionInvocation.init(DefaultActionInvocation.java:388)
    com.opensymphony.xwork2.DefaultActionProxy.prepare(DefaultActionProxy.java:187)
    org.apache.struts2.impl.StrutsActionProxy.prepare(StrutsActionProxy.java:61)
    org.apache.struts2.impl.StrutsActionProxyFactory.createActionProxy(StrutsActionProxyFactory.java:39)
    com.opensymphony.xwork2.DefaultActionProxyFactory.createActionProxy(DefaultActionProxyFactory.java:47)
    org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:478)
    org.apache.struts2.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:395)
    note The full stack trace of the root cause is available in the Apache Tomcat/7.0.20 logs. 

and from users perspective this is not desirable right, so how to tackle such problems. I am using Eclipse Juno, Windows XP, MySQL 5.5.

Answer 1

Exceptions are the results of the program or developer can't handle the situation with abnormal behavior. In this case the developer could know that the exception is thrown and could make some actions toward resolving the case.

The ordinary user doesn't need to know about any exception but the system administrators actually do. So, logging exceptions are good making the possibility to solve any problems further.

This is also useful on the development stage, when the developer needs to debug the issue via printing stacktrace, rethrowing exception. Rarely applicable in this situation the catching and ignoring exceptions.

In the normal situation exceptions should be caught, logged and rethrown. But in the Struts2 you could handle uncaught exceptions via creating the default application interceptor stack

<interceptor-stack name="appDefaultStack">
  <interceptor-ref name="defaultStack">
    <param name="exception.logEnabled">true</param>
    <param name="exception.logLevel">ERROR</param>
  </interceptor-ref>
</interceptor-stack>

any exceptions not caught by this application will be logged and then handled by the global exception mapping

<global-exception-mappings>
  <exception-mapping exception="java.lang.Exception" result="error"/>
</global-exception-mappings>

<global-results>
  <result name="error">/error_page.jsp</result>
</global-results>

Answer 2

The user doesn't need to know there was a database exception, the developer does.

The specific exception should be logged. The user should see that an operation failed. Generally you'd either simply report this through normal S2 means, e.g., an error message.

You may also throw an application-specific exception and use S2's declarative exception handling.

You may use declarative exception handling to handle any or all low-level exceptions, but IMO that's either too general, or too tedious.