Using a simple variant of the template method design pattern, 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);
        }
    }
}          

See an example at the Central Exception Reporting Sample Application, site http://excrep.berlios.de/

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 you should use an own UiAction base class as was described earlier.

Attention: Propagating an exception from the method actionPerformed will leave Swing in a dirty state. Sometimes the focus of a menu item will be highlighted in another place, than where Swing assumes it to be. So you should on the one hand install such a last-resort exception reporting, but nevertheless you need an UiAction for reporting exceptions in all user-triggered actions.

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 it's stack trace and diagnostically useful attributes of the request, session, and application.

See an example at the Central Exception Reporting Sample Application, site http://excrep.berlios.de/

In Struts 1.3.8 you have the possibility to define a central exception handler using the <global-exceptions> element of file struts-config.xml. The central exception handler class must implement the interface org.apache.struts.action.ExceptionHandler. This works very well and has access to the causing UI component.

A template method for the execute methods you need only, if you want to handle other action related issues centrally, e.g. transaction management.

See an example at the Central Exception Reporting Sample Application, site http://excrep.berlios.de/

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

The JavaServer Faces life cycle (see http://java.sun.com/j2ee/1.4/docs/tutorial/doc/images/jsfIntro-lifecycle.gif) is directed by an implementation of the interface Lifecycle (in the package javax.faces.lifecycle. The reference implementation of Sun is com.sun.faces.lifecycle.LifecycleImpl).

When the web application is started, a LifecycleFactory (also in package javax.faces.lifecycle, reference implementation of Sun is com.sun.faces.lifecycle.LifecycleFactoryImpl) is asked to return a Lifecycle object. Normally the standard implementation will be taken. But you have the possibility to change the LifecycleFactory, and to return your own Lifecycle implementation.

In detail: Here are the two classes, which we have written. You can subclass the reference implementation, or you can completely implement the interface. We take the first approach.

package myPackage; //MyLifecycleFactoryImpl.java
  
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
    }
  }

}      

Now we still have to instruct JavaServer Faces, that we want to use our own LifecycleFactory implementation instead of the default implementation. This we have to do in the file faces-config.xml (a configuration file similar to 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>        

Having done this, our implementation of the LifecycleFactory will be used, which in turn will deliver in the method getLifecycle (see before) our own Lifecycle implementation.

If there remain questions, I will try to answer them. You can mention my addresses in this little howto, so that future students can ask me, if necessary.

Siamak Haschemi, www.haschemi.org E-Mail: info (at) haschemi.org,

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)

public static void setDefaultUncaughtExceptionHandler(
  Thread.UncaughtExceptionHandler eh
)

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.

You can use the doclet multex.tool.ExceptionMessagesDoclet to collect all exception message text patterns from the exceptions. You must specify the sources to scan as usually for a doclet. You must pass the output .properties file name to the doclet option -out.

By executing the doclet on the upper examples the following property definitions will be appended to the given -out file:

org.company.project.Account$CreditLimitExc = Taking {0} units from your ac\
 count will leave less than your creditLimit {1} units on it.
org.company.project.FileUtil$LoadFileFailure = Failure loading file {0} by user {1}

As Javadoc removes white space at the end of each comment line, and java.util.Properties.load ignores the \ indicating line continuation and whitespace at the beginning of the next line, it is somehow difficult to make continuation lines with an intuitive spacing. You can either split the long message text inside of a word, as e.g. the word account in the example was split, or you can insert a Properties escape sequence for whitespace at the end of the line, e.g. a \t or a \u0020.

<target name="exception" depends="compile" 
    description="Collect all exception message texts in the fb6 software into one file"
>
    
    <property name="ExceptionResourcesFile" 
        value="${CLASS_DESTINATION}/ExceptionResources.properties"
    />
    <echo file="${ExceptionResourcesFile}" append="false">
    #Generated by ANT-Target _resources. Do not edit.
multex.MsgText.causeMarker = Ursache: 
    #From here are following the message texts for the exceptions in the software system.
    #They are all collected from the main Javadoc texts of each exception declaration.
</echo>
    <javadoc
        access="private"
        classpathref="compile.classpath"
        doclet="multex.tool.ExceptionMessagesDoclet"
        docletpathref="compile.classpath"
        source="1.6"
        useexternalfile="yes"
        encoding="ISO-8859-1"
    >
        <arg value="-out"/> 
        <!--Message texts will be appended to this file.-->
        <arg file="${ExceptionResourcesFile}"/>
        
        <!--All exceptions in all Java files in this directory will be processed.-->
        <fileset dir="java"/>
    </javadoc>
</target>

The former example works as follows. The echo element creates a file ExceptionResources.properties with a string resource for the key multex.MsgText.causeMarker. This defines the german translation for the default cause marker CAUSE:. Then the multex.tool.ExceptionMessagesDoclet appends all exception message text patterns for all exceptions declared in all Java files in the directory java to the .properties file. The given encoding is used to interpret the Java source files. For writing to the -out file always encoding ISO-8859-1 is used, as .properties files must use it.