On 8/7/07, Nick Outram <[EMAIL PROTECTED]> wrote:
> James.Strachan wrote:
> >
> > On 8/7/07, James Strachan <[EMAIL PROTECTED]> wrote:
> >
> > I've just added to trunk a little try/catch style routing DSL.
> >
> > In Java we can't use try/catch/finally words so I've initially gone with
> > this
> >
> > from("direct:start").
> > tryBlock().
> > process(validator).
> > to("mock:valid").
> > handle(ValidationException.class).to("mock:invalid");
> >
> > which is maybe not the easiest thing to read; but tryBlock / handle is
> > a replacement for try/catch. (Maybe tryBlock/catchBlock is more
> > consistent?). Any name suggestions most welcome! (Its often the
> > hardest part of programming, coming up with good names for things).
> >
> > In XML its a little easier on the eye. e.g. here's a validation test
> > case to ensure that messages are delivered to different endpoints
> > depending on whether they are valid or not...
> > https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-spring/src/test/resources/org/apache/camel/component/validator/camelContext.xml
>
> Hmm, not sure about the try/catch approach :confused: as it makes the DSL a
> bit verbose. I think I'd prefer the implicit try/catch that we already have
> with the ErrorHandler; more of an AOP approach. How about using an
> ErrorRoute instead of an ErrorHandler? Once an error is on the ErrorRoute it
> has the full semantics of the DSL available for filtering/splitting etc.
>
> We'd have to add semantics to allow retry to an endpoint. Something like:
>
> from("error:start").
> .choice()
> .when(error(ValidationException.class)).to("seda:a")
> .when(error(BusinessDataException.class)).to("seda:b")
>
> .when(error(SystemException.class)).retry().useCollisionAvoidance().maximumRedeliveries(0)
> .useExponentialBackOff()
>
>
> .when(error(PooException.class)).retry().useCollisionAvoidance().maximumRedeliveries(-1)
> .useExponentialBackOff()
> .otherwise().to("seda:c");
>
> Where the retry() will post the message back to the route that generated the
> error...
> I just threw the 'when(error(...' semantic in to make it explicit but maybe
> the exception class is already available in the context?
> As in this example I'd want to be able to separately configure the retry
> behaviour for different exceptions.
Interesting idea! Its certainly much cleaner than my attempt! :) I
think some folks might still want try/catch in some circumstances -
however I agree we need nicer error handling in the DSL.
I'm wondering about something like...
// lets setup the error handler first
onError(MyException.class).maximumRedeliveries(5).onFail().to("seda:c")
// now lets do the route
from("foo").to("bar");
I guess if we define the error handler in the middle of a route we
might need some kinda escape expression to go back to the 'real route'
from the error handler route. e.g.
// this is bad...
from("foo").
onError(MyException.class).maximumRedeliveries(5).onFail().to("seda:c").
to("bar"); // by default this would still be part of the error handler
maybe something like
from("foo").
onError(MyException.class).
maximumRedeliveries(5).onFail().to("seda:c").
onError(Bar.class).
to("seda:d")
onSucccess().
to("bar");
i.e. the onError(Class) stuff starts adding an error route for a
specific type of exception (which also allows you to configure retry
policy & the dead letter destination etc)
Thoughts?
--
James
-------
http://macstrac.blogspot.com/
