synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Asankha C. Perera" <>
Subject Re: Exception handling
Date Thu, 02 Apr 2009 14:22:13 GMT
Hi Eric
> thanks for your reply. Humans life would be to boring, if we would always share the same
opinion. ;-)
Of course I may be wrong too and in some cases we maybe able to improve 
the code we already have, and I am fully open to change which is good 
for the project :-)
>> Item 43: Throw exceptions appropriate to the abstraction
> This is very, very important. And at this point I would rather also like to add, that
one sometimes should also take care to not violate this indirectly via chaining the cause
which brings along all the details which should be abstracted. That's via a favour to create
new exceptions at that point a properly the details at the abstraction boarder.
For Synapse, I am not sure I fully agree.. since the main dependency 
with Axis2 sorts of causes this.. see we get messages from transports, 
into Axis2, then to Synapse for mediation, then again through Axis2 to 
transports and out etc.. I do not think keeping the original cause 
should be abstracted, but left as-is for easier problem resolution via 
logs etc.
> Ok, if you decide that you can handle this exception accordingly, I totally agree. But
in this case why should you rethrow it? If you can't handle it and decide the caller might
be able to handle it (not arguing about checked or unchecked at this point at all to concentrate
on one topic), you can't log the error as it might be not a real problem for the caller which
may be able to compensate. Logging some general context info for later correlation is another
topic. This way you also avoid logging the same exception a couple of times, as the caller
can't know whether something has already been logged and from his perspective it is the first
time he is catching this exception. I don't think you use the SynapseException only for wrapping,
but also for "self created" exceptions, or?
Another one from Joshua "..To avoid this problem, higher layers should 
catch lower-level exceptions and, in their place, throw exceptions that 
are explainable in terms of the higher-level abstraction." - note that 
no where in the code do we catch a SynapseException and log or re-throw 
it.. thats bound by developer discipline so that each exception is only 
uniquely logged once with most of the information about its cause. 
Within the Synapse code I do not think there is any outside layer that 
is able to handle something the Synapse layer beneath could have 
handled.. I think we need to dig into the code and take some concrete 
examples, and see if we can really improve things with an alternative, 
and if we can definitely improve it
> Anyway it looks like there has already been some discussion about it and I do not want
to change something about, just make sure I'm not missing a very special reason. ;-)
No discussion is always good, and questioning to improve what we have .. 
I think best is to keep an eye for something related to exception 
handling we could improve when we next look at some piece of code, and 
then take it up for discussion/dissection and more analysis with 
everyone..  :-)


Asankha C. Perera

View raw message