Generating first failure data capture (FFDC) records

FFDC records include the exception stack and optional additional data that is recorded when an unexpected exception is caught by your code. Methods on the com.ibm.ws.ffdc.FFDCFilter class are used to generate these records, and there are a number of methods that might cause a variety of data to be captured.

Example

A typical use of the FFDCFilter class is as follows:

try{
            // … do something
    } catch (Exception e) {
            FFDCFilter.processException(e, getClass().getName(), unique-probe-id);
            if (TraceComponent.isAnyTracingEnabled() && tc.isDebugEnabled()) {
                Tr.debug(tc, "Exception when doing something; " + e);
            }
            return;
    }

Where the source id (class name in this example) and the unique probe id (typically the source code line number) combine to provide the exact location in the source code that generates the resulting record. By default, the records are written to the ${server.output.dir}/logs/ffdc directory.

The file space used by the FFDC records in the case of a persistently occurring exception is limited by automatic filtering of duplicate records. For any matching source id, probe id, and exception name, at most 10 exceptions with unique messages are written per day.

Feature code can contribute data to FFDC records by registering a com.ibm.ws.ffdc.DiagnosticModule implementation with the FFDC class. Feature code can also intercept FFDC records by registering a com.ibm.wsspi.logging.IncidentForwarder implementation with the FFDC class.

Parent topic: Configure tracing and logging for features