synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hubert, Eric" <>
Subject Exception handling
Date Thu, 02 Apr 2009 09:43:26 GMT
Hi Synapse devs,

No worries, I don't want to start a discussion about exception handling in general, I just
would like to understand the reasoning of your design choice. I stumbled over some areas in
the code where I noticed that an original exception is caught, logged AND rethrown wrapped
inside a SynapseException or SynapseUtilException (specific RuntimeExceptions). The original
exception is then mostly logged as an error, no matter whether the caller may consider the
exception to be critical or easily recoverable. If he is able to recover, the original problem
is already logged as an error and he may only add a warning about the way he could recover.

The good thing is that the almost the whole code looks pretty consistent in this regard and
I bet this is due to the following comment 
"We always log each exception the first time it is caught, and throw a SynapseException with
an appropriate error message that tries to give out additional information on why the exception
in the developer guidelines at (Would
it make sense to make this guideline easier available? Integrate or link it from the main

What is the reasoning of this exception handling/logging approach?

So far I was used to the following rule(s):
Either throw (chaining/wrapping of original exception) or log, except on component boundaries
where original exceptions have to be logged AND new exceptions created and thrown (no chaining/wrapping
of original exception for this case, as implementation details and concrete stack/dependencies
shall be hidden from the caller). So far I never had problems with this approach. What are
other's experiences?

Of course I will follow the chosen approach - this is more out of personal interest.

View raw message