synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <>
Subject Re: Exception handling
Date Thu, 02 Apr 2009 09:56:00 GMT
Interesting question. Personally, I've always considered the log and
throw approach as an anti-pattern.


On Thu, Apr 2, 2009 at 11:43, Hubert, Eric <> wrote:
> 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 occurred."
> in the developer guidelines at
(Would it make sense to make this guideline easier available? Integrate or link it from the
main page?).
> 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.
> Regards,
>  Eric

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message