In my opinion, we should fail fast. Without a custom aggregation strategy, who's logic is application dependent and should have all the necessary information, there is not much you can do.
For me 2) ignore the exceptions is not a good idea 1) is a better option, although a bit tricky, because the 2nd exception may be a consequence of the first and environment/context dependent. The best solution for me is to implement the custom aggregation strategy (as clumsy as it is), or add validation before the split, if such a scenario is likely. We cannot really compensate for low quality of input data, and imho the way it's implemented now is just fine. My $0.02, Hadrian On Jan 6, 2011, at 8:57 AM, Claus Ibsen wrote: > Hi > > Give a scenario you use a splitter EIP to process sub messages. > > from X > split body > process step 1 > process step 2 > end > to Y > > process step 1 and 2 is part of the sub processing of the sub messages. > For example if the current message contains A,B,C,D,E and we split by > comma. We will get 5 sub messages. > > Now suppose that this happens > A = ok > B = ok > C = throws IOException > D = ok > E = throws UnknownOrderException > > That leaves us with several scenarios. > > Mind that all this can always be handled and 100% controlled by end > user if you use your custom AggregationStrategy. > In here you can control if exceptions should be ignored and whatnot. > > But that is a bit clumsy to use as you need to code Java code. So we > are talking about options and default values on the Splitter EIP. > > Currently what happens today, is that the exception from C is > propagated, which means that after the splitter EIP is finished. > the IOException will be set on the current message (the input for the > splitter), which again causes Camel to detect the exception > and break out continue processing. Which means the message will not be > send to Y. > > > What we could do > 1) Improve this so the splitter collects all the exceptions, so there > is some BatchExecutionException which contains both IOException and > UnknownOrderException. > 2) Add new option to ignore those exceptions all together, so Camel > will continue processing and send the message to Y. > > > Mind that this scenario in fact also applies for some of the other EIP > patterns such as > - multicast > - recipient list > > > Also how far should we go to keep backwards compatibility? > > > PS: In this example we could enable the stopOnException option which > would cause the splitter to stop asap it detects an exception. Which > means that it would only do > A = ok > B = ok > C = throws IOException > > > > > -- > Claus Ibsen > ----------------- > FuseSource > Email: cib...@fusesource.com > Web: http://fusesource.com > Twitter: davsclaus > Blog: http://davsclaus.blogspot.com/ > Author of Camel in Action: http://www.manning.com/ibsen/
