[...]This is one of the most annoying error-handling antipatterns. Either log the exception, or throw it, but never do both.[...]

In case you want to chain exception and then only print/log exceptions at the higher layer, I noticed that if you use the XML Formatter(in java), the cause exception (the source of the exception) is not printed. Only if you use the Simple Formatter, the cause exception stack trace is printed.

don’t know why, though?

BR,
~A

Alas, many common api’s and vendor api’s now use the exception syntax where better decompostion and error reporting would be cleaner, more maintainable, more portable, more extensible, and just plain more correct. So what’s a poor developer to do?

Wrap the pathological exceptions. Design layered services which appropriately abstract implementation details at each level and report results (including ‘error’ cases) in the semantics of the usage domain, not the implementation details. Thus the reply about needing the trace detail is a bit off base. One can always log stuff anyway, if needed.

As a programming technique, Ricky Clarkson’s approach: using a callback is one of the better approaches that I’ve seen. Kudos.

But the fundamental issue is still design, design, design.

Instead of


void method() throws IOException
{
new FileStuff().write();
}

I’d have:

void method(SideEffect ioExceptionHandler)
{
try
{
new FileStuff().write();
}
catch (IOException exception)
{
ioExceptionHandler.run(exception);
}
}

interface SideEffect[T]
{
void run(T input);
}


Then they can be chained fairly easily, and you don’t feel the need to deal with exceptions before you need to. It also gets away from the ugly try..catch in client code – generally a client will satisfy a method parameter requirement better than they will handle an exception.

Throwing an exception does not necessarily cause output.
Printing a stack trace does not necessarily write to the log.
Sometimes an exception must be thrown even though it will be gracefully dealt with higher in the stack, but you still want to log that it happened (and where it happened).

however, in a system where exceptions can pop from deep inside multiple places, i’d much rather have the undwinding trace there in one place. back in the good ol’ days of batch computing with *card decks* and *printer listing*, this is precisely the approach we’d take on big codes because you had to make as certain as possible that what came out before the crash was sufficient to diagnose and repair the code without another run. this is particularly important for large computation jobs that run for hours before blowing apart.

so while there is certainly grounds for moderation in logging every twitch that happens, there is also great wisdom in making sure that acquiring the one missing piece of information you need to diagnose the problem doesn’t require recreating conditions which may be expensive or impossible to reproduce. you can always ignore log information – it is very difficult to use information that is not there.