In order to report all uncaught exceptions in a Swing application, which occur during the execution of an UI-event-triggered action, it is sufficient to install one central exception handler using the undocumented system property sun.awt.exception.handler, see more in a JGuru discussion.

This undocumented behaviour is wrapped by a MulTEx service. You can implement the interface multex.AwtExceptionHandler, and install this class by the method multex.Awt.setAwtExceptionHandlerClass(...). Then any exception propagating up to the AWT/Swing event-dispatch thread will be reported by the handler's method handle(Throwable). In this method you should call a multex.Swing.report() method.

In order to block input to the GUI application while reporting an exception, it is necessary to locate the application's frame and use it in the central exception handler's call to report(...) as the ownerHook.

If an application has several frames, and it is not possible to determine automatically, which UI component must be blocked during exception reporting, then there is a more work-intensive way to central exception reporting.

You should write your own class, e.g. UiAction as a subclass of javax.swing.AbstractAction:

          public class UiAction extends javax.swing.AbstractAction {
             final void actionPerformed(ActionEvent ev){
               try{actionPerformedWithThrows(ev);
               }catch(Exception ex){multex.Swing.report(ev.getSource(), ex);
               }
            }
          }
	      

Note: Not yet tested by me personally, but used in a project known to me.

In order to report all uncaught exceptions in a JSP/servlet application, which occur during the execution of an UI-event-triggered action, it is sufficient to install one central error page. See section “2.4.2 Request Time Processing Errors” of the Sun Java Server Pages Specification about this.

In Tomcat you can do this in the deployment descriptor web.xml by an “error-page” directive. E.g.:

          <error-page>
              <exception-type>java.lang.Throwable</exception-type>
              <location>/system/errorPage.jsp</location>
          </error-page>

        

This means, that any exception, including Throwable, will be reported by forwarding to the JSP page /system/errorPage.jsp. The error page itself must be marked as such by setting the page directive’s isErrorPage attribute to true, e.g.:

        <%@page contentType="text/html" isErrorPage="true" %>
        

In such an error page you should report not only the message texts of the exception chain, but also its stack trace and diagnostically useful attributes of the request, session, and application.

TODO: Give examples.

As for Struts I did not find a possibility to set a central exception handler, you must use the approach with subclassing the Struts Action class.

You should write your own class, e.g. UiAction as a subclass of org.apache.struts.action.Action:

          public class UiAction extends org.apache.struts.action.Action {
            public ActionForward execute(
                final ActionMapping mapping,
                final ActionForm form,
                final HttpServletRequest request,
                final HttpServletResponse response
            ){
               try{return executeWithThrows(mapping, form, request, response);
               }catch(Exception ex){... //report(ex)
               }
            }
          }
	      

This class's execute method will be invoked by Struts. It calls itself the method executeWithThrows of its subclass, catching all Exception-s of it. This will report the caught exception by storing it in the session attribute “EXCEPTION” and its message chain by Struts' saveErrors(...), and then forwarding to either the JSP input page, if specified in the struts-config.xml, or to the errorPage.jsp as last-resort.

Note: The report action in the catch-block is quite complex, so you should look at the example running on the webserver http://fb6.tfh-berlin.de/, which can be obtained from the author, in the moment at Examples for Central Exception Reporting.

Here is described the solution of the student project TriplePlay in SS 2005.

Der JavaServer Faces Lebenszyklus (siehe http://java.sun.com/j2ee/1.4/docs/tutorial/doc/images/jsfIntro-lifecycle.gif) wird gesteuert von einer Implementation der Schnitstelle Lifecycle (im Paket javax.faces.lifecycle, Refenrenzimplementation von sun unter com.sun.faces.lifecycle.LifecycleImpl).

Beim Start der Webapplikation wird eine LifecycleFactory (ebenfalls im Paket javax.faces.lifecycle, Refenrenzimplementation von sun unter com.sun.faces.lifecycle.LifecycleFactoryImpl) aufgefordert, eine Lifecycle zu liefern. Normalerweise wird die Standardimplementierung genommen. Man hat aber die Möglichkeit, die LifecycleFactory auszutauschen uns somit seine eigene Lifecycle zurück zu liefern.

Werden wir konkret: Hier die zwei Klassen, die wir geschrieben haben. Man hat die Möglichkeit, die von der Referenzimplementation gelieferte Klasse zu spezialisieren, oder die Schnittstelle komplett selbst zu implementieren. Wir wählten die erste Möglichkeit.

package myPackage; //MyLifecycleFactoryImpl.java

public class MyLifecycleFactoryImpl extends  
com.sun.faces.lifecycle.LifecycleFactoryImpl {
  
import javax.faces.FacesException;
import javax.faces.lifecycle.Lifecycle;

public class MyLifecycleFactoryImpl extends  
com.sun.faces.lifecycle.LifecycleFactoryImpl {
  public Lifecycle getLifecycle(final String i_lifecycleId) throws FacesException {
    return new MyLifecycleImpl();
  }
}

/////////////////////////////////////////////////////////////////////
package myPackage; //MyLifecycleImpl.java 

import javax.faces.FacesException;
import javax.faces.context.FacesContext;

public class MyLifecycleImpl extends com.sun.faces.lifecycle.LifecycleImpl  
{
  public void execute(final FacesContext io_facesContext) {
    try {			
      super.execute(io_facesContext);			
    }
    catch(final FacesException e) {
      // handleExceptions here
    }
  }
}
	      

Nun muss man JavaServer Faces noch mitteilen, dass man seine eigene LifecycleFactory-Implementation statt der Standardimplementation verwenden will. Das geschieht über die faces-config.xml (eine Konfigurationsdatei ähnlich wie struts-config.xml)

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE faces-config PUBLIC
           "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"
           "http://java.sun.com/dtd/web-facesconfig_1_0.dtd">

<faces-config>

       ...

	<factory>
		<lifecycle-factory>myPackage.MyLifecycleFactoryImpl</lifecycle-factory>
	</factory>

       ...

</faces-config>

        

Damit wird unsere Implementation der LifecycleFactory verwendet, die widerum in der Methode getLifecycle (s.o.) unsere eigene Lifecycle-Implementation zurückliefert.

Falls noch Fragen sind, werde ich gerne versuchen, diese zu beantworten. Ansonsten können Sie gerne meine email-adresse zu diesem kleinen Howto angeben, damit sich künftige Studenten im Fall der Fälle auch an mich wenden können.

Siamak Haschemi, mail: siamak.h (bei) gmx.de

In order to report all uncaught exceptions of all background threads, you must place all the threads in your own ThreadGroup. For this ThreadGroup you redefine the method

void uncaughtException(Thread t, Throwable e)

But for a long-living thread, usually serving commands or alike, and not triggered by a user action. we cannot tolerate to stop the thread. Thus such a server thread should catch in its command loop in the run() method any exception and report it to a logging destination.

Also here it would be useful to inform the user, if any exists, that a required service failed, and where is the appropriate logfile.