There are two types of stack traces, thread-level and process-level. When you catch an exception in your component, you can print the thread-level stack trace using the printStackTrace method in the component’s try/catch block:
try {
// whatever
}
catch (Exception e) {
{
// Important to avoid empty catch blocks
// Remember to output error information
e.printStackTrace();
}
Many APIs such as JDBC and JNDI throw generic exceptions, with the original error information embedded as a nested exception. For JDBC, you can retrieve the nested exception using the java.sql.SQLException.getNextException method. Record the nested exception message and stack trace.
You may also need to print naming exceptions. For example, when creating proxies in an EJB client, a naming exception may be thrown. Since the lookup method must throw NamingException, other errors can be embedded, such as the NamingException root cause. Often, you must retrieve details about the embedded error to diagnose the problem. The code below demonstrates how to retrieve and print the root cause information for a JNDI NamingException:
catch (NamingException ne)
{
System.out.println("Naming exception: " + ne.toString());
ne.printStackTrace();
throwable rc = ne.getRootCause();
if (rc != null)
{
System.out.println("\nRoot cause: + rc.toString();
rc.printStackTrace();
}
}
If you do not catch exceptions in component code, EAServer catches the exception, logs the error, and aborts method execution. However, the server may not record all information required to debug the problem, such as nested exceptions. For this reason, you should catch exceptions in your own code and log the information required to diagnose the problem.
If serious internal errors occur, the Java VM may abort and produce a process-level stack trace that contains trace information for all Java threads, signals received, and thread states at the time of the error.
