Russell, I think your exception logging policy is good. I spoke to Glen the other week about FFDC, so it may be worth mentioning this concept for anyone who is not familiar with it.
FFDC is "first failure data capture". The principle is that when an error is detected that is likely to be due to a bug, then full diagnostics should be created to enable debugging *without* having to reproduce the failing scenario. A typical example is where the state of an object has become 'broken', i.e. certain invariants are no longer true. This is a "bread and butter" for certain types of system software. For instance, some systems, when they encounter such an error, issue an operator message, make a log entry (regardless of whether normal activity is being logged), atomically dump the contents of the current address space to disk for offline analysis, and throw an exception to the caller. There is typically a convention so that callers know whether a particular exception has already resulted in FFDC, as doing FFDC multiple times can sometimes cause difficulties. (Other kinds of error may occur in normal usage and these just result in an exception being thrown to the caller who is then responsible for FFDC if necessary.) Many platforms do not have an atomic dump mechanism and this is not supported by java, so the best we can do in Axis is to log the stack trace from the exception. The bottom line when coding error handling is to decide whether the error is likely to be due to a bug, in which case full diagnostics need creating right there and then, or whether the error is softer, in which case some lower-level diagnostics can be created and the caller is left to decide whether this requires full diagnostics. Glyn
