You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by pmcb55 <mc...@dnb.com> on 2013/05/12 13:17:54 UTC
Why do Camel core methods still throw Checked Exceptions (everyone
agrees they're 'bad' now, right?)
I've been using Camel for a while (and it's great), but one issue bugs me -
many of the methods in the core Camel interfaces throw Checked Exceptions,
e.g. the fundamental 'void process(Exchange exchange) *throws Exception*;',
or CamelContext methods, like 'addRoutes()' or 'start()'.
Doesn't the Java world now pretty-much accept that Checked Exceptions are
generally bad, isn't this debate over
(http://jyops.blogspot.ie/2012/03/why-should-you-use-unchecked-exceptions.html)?!
Hibernate already made the decision to drop Checked Exceptions:
http://stackoverflow.com/questions/4609870/why-hibernate-changed-hibernateexception-to-runtimeexception-unchecked,
and isn't Camel in the same class of 'thing' as Hibernate - i.e. a very
widely used Java developer framework.
Does the Camel community still think they are 'good'? I don't! Maybe it's
just that a change would be backward-compatibility-breaking, and maybe it's
on the cards for Camel 3.0 - so I'm just asking (I couldn't find anything
searching this site).
So rather than expose these nasty Checked Exceptions to my code (because
they tend to ripple up, or I have stupid try{}/catch(Exception){}' blocks in
my code, I'm considering wrapping *all* the Camel calls (that my code uses)
in methods that just catch these 'Exceptions' and throw 'RuntimeExceptions'
instead.
PMD already has a warning about signatures using 'throws Exception':
SignatureDeclareThrowsException (so Camel falls down there already!), but
even my wrapper code will get caught out by the related PMD warning of
AvoidCatchingGenericException
(http://pmd.sourceforge.net/pmd-4.2.6/rules/strictexception.html).
Wouldn't all this nastiness go away if Camel went the Hibernate route (and
the wider industry route!?) and just dropped Checked Exceptions...? Is there
any general community advice for current Camel 2.x users (e.g. just wrap the
'offending' methods if you don't like them!)??
And I'm really just asking the question here - there's no need for a
Checked/Unchecked debate. If the Camel community (or just the committers)
consider the current situation appropriate then I'm perfectly fine with
that, and I'll just go with the wrapper methods for my systems.
Pat.
--
View this message in context: http://camel.465427.n5.nabble.com/Why-do-Camel-core-methods-still-throw-Checked-Exceptions-everyone-agrees-they-re-bad-now-right-tp5732364.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Why do Camel core methods still throw Checked Exceptions
(everyone agrees they're 'bad' now, right?)
Posted by pmcb55 <mc...@dnb.com>.
Thanks a million for the response Hadrian.
That was what I kinda suspected (i.e. legacy reasons). Your response makes
me very confident now that wrapping the offending methods is the correct
action for me right now (it's pretty trivial for me to do anyway). That way
I get rid of the nasty (i.e. 'noisy') Checked Exceptions in my code, and I
may also be isolated from at least some of the breaking changes that may
come in Camel 3.0 (but of course you're right, backward compatibility will
indeed be a huge issue right across the Camel codebase, if it ever actually
happens...!).
--
View this message in context: http://camel.465427.n5.nabble.com/Why-do-Camel-core-methods-still-throw-Checked-Exceptions-everyone-agrees-they-re-bad-now-right-tp5732364p5732665.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Why do Camel core methods still throw Checked Exceptions (everyone
agrees they're 'bad' now, right?)
Posted by Hadrian Zbarcea <hz...@gmail.com>.
FWIW, +1 Pat (my personal opinion).
My explanation, legacy stuff. Hopefully it'll be addressed in 3.0.
Backward compatibility will really be a serious issue.
Hadrian
On 05/15/2013 01:57 PM, pmcb55 wrote:
> Hi Christian,
>
> Thanks for the reply.
>
> Basically the issue with Camel throwing Checked Exceptions is that my code
> now has to declare those Checked Exceptions, which I concern just 'noise'
> (i.e. they add no value to my code, and now my Unit tests are infected with
> 'throws Exception' clauses that they really shouldn't care about, and my
> methods to initialise Camel need unhelpful try{}/catch{} blocks). But just
> like Hibernate, all these exceptions are really 'fatal' errors that my
> application can't handle anyway, and so should propagate all the way up (and
> like you say, if 'process()' throws *any* kind of exception, it will be
> caught by 'onException()' anyway). So as Joshua Bloch states in the famous
> 'Effective Java' book, only use Checked Exceptions for things your app can
> be expected to be able to handle.
>
> Again, I'd read the link I sent about Checked Exceptions being 'dead' in
> Java development to really understand where I'm coming from
> (http://jyops.blogspot.ie/2012/03/why-should-you-use-unchecked-exceptions.html).
> (And ok, ok, lots of people will still probably cling to them, but for
> frameworks like Hibernate and Camel I really don't see that they add any
> value at all over Unchecked Exceptions).
>
> So maybe this issue just never arose before, and I'll just go ahead and wrap
> my Camel calls in utility methods that convert any checked exceptions to
> unchecked ones - it's no big deal for me to do this, but I think it may be
> worth the Camel community looking at the issue (like the Hibernate guys
> did).
>
> Cheers,
>
> Pat.
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Why-do-Camel-core-methods-still-throw-Checked-Exceptions-everyone-agrees-they-re-bad-now-right-tp5732364p5732627.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: Why do Camel core methods still throw Checked Exceptions
(everyone agrees they're 'bad' now, right?)
Posted by pmcb55 <mc...@dnb.com>.
Hi Christian,
Thanks for the reply.
Basically the issue with Camel throwing Checked Exceptions is that my code
now has to declare those Checked Exceptions, which I concern just 'noise'
(i.e. they add no value to my code, and now my Unit tests are infected with
'throws Exception' clauses that they really shouldn't care about, and my
methods to initialise Camel need unhelpful try{}/catch{} blocks). But just
like Hibernate, all these exceptions are really 'fatal' errors that my
application can't handle anyway, and so should propagate all the way up (and
like you say, if 'process()' throws *any* kind of exception, it will be
caught by 'onException()' anyway). So as Joshua Bloch states in the famous
'Effective Java' book, only use Checked Exceptions for things your app can
be expected to be able to handle.
Again, I'd read the link I sent about Checked Exceptions being 'dead' in
Java development to really understand where I'm coming from
(http://jyops.blogspot.ie/2012/03/why-should-you-use-unchecked-exceptions.html).
(And ok, ok, lots of people will still probably cling to them, but for
frameworks like Hibernate and Camel I really don't see that they add any
value at all over Unchecked Exceptions).
So maybe this issue just never arose before, and I'll just go ahead and wrap
my Camel calls in utility methods that convert any checked exceptions to
unchecked ones - it's no big deal for me to do this, but I think it may be
worth the Camel community looking at the issue (like the Hibernate guys
did).
Cheers,
Pat.
--
View this message in context: http://camel.465427.n5.nabble.com/Why-do-Camel-core-methods-still-throw-Checked-Exceptions-everyone-agrees-they-re-bad-now-right-tp5732364p5732627.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Why do Camel core methods still throw Checked Exceptions
(everyone agrees they're 'bad' now, right?)
Posted by Christian Müller <ch...@gmail.com>.
Hi pmcb55!
I would like to understand what your issue is with the checked exception in
the Processors process method. As a Camel user, you may derive from
Processor and implement your custom business code in the process method. By
declaring "throws Exception" on this method, you are free to throw any
exception you want. And, in contrast the the Hibernate case, you don't deal
directly with this exception (declaring it in your code, try/catch the
exception, ...).
You only deal with it if you declare an onException() or doTry()/doCatch()
block which is totally optional - even if it's a checked or unchecked
exception.
If you don't like it, you can also implement your business logic in a bean
which doesn't implement or extend a Camel interface/class and use the
camel-bean component [1] to invoke this bean. Here you are free to only
throw unchecked exceptions.
So, whats the "nasty" thing for you? I didn't get it...
[1] http://camel.apache.org/bean.html
Best,
Christian
On Sun, May 12, 2013 at 1:17 PM, pmcb55 <mc...@dnb.com> wrote:
> I've been using Camel for a while (and it's great), but one issue bugs me -
> many of the methods in the core Camel interfaces throw Checked Exceptions,
> e.g. the fundamental 'void process(Exchange exchange) *throws Exception*;',
> or CamelContext methods, like 'addRoutes()' or 'start()'.
>
> Doesn't the Java world now pretty-much accept that Checked Exceptions are
> generally bad, isn't this debate over
> (
> http://jyops.blogspot.ie/2012/03/why-should-you-use-unchecked-exceptions.html)
> ?!
>
> Hibernate already made the decision to drop Checked Exceptions:
>
> http://stackoverflow.com/questions/4609870/why-hibernate-changed-hibernateexception-to-runtimeexception-unchecked
> ,
> and isn't Camel in the same class of 'thing' as Hibernate - i.e. a very
> widely used Java developer framework.
>
> Does the Camel community still think they are 'good'? I don't! Maybe it's
> just that a change would be backward-compatibility-breaking, and maybe it's
> on the cards for Camel 3.0 - so I'm just asking (I couldn't find anything
> searching this site).
>
> So rather than expose these nasty Checked Exceptions to my code (because
> they tend to ripple up, or I have stupid try{}/catch(Exception){}' blocks
> in
> my code, I'm considering wrapping *all* the Camel calls (that my code uses)
> in methods that just catch these 'Exceptions' and throw 'RuntimeExceptions'
> instead.
>
> PMD already has a warning about signatures using 'throws Exception':
> SignatureDeclareThrowsException (so Camel falls down there already!), but
> even my wrapper code will get caught out by the related PMD warning of
> AvoidCatchingGenericException
> (http://pmd.sourceforge.net/pmd-4.2.6/rules/strictexception.html).
>
> Wouldn't all this nastiness go away if Camel went the Hibernate route (and
> the wider industry route!?) and just dropped Checked Exceptions...? Is
> there
> any general community advice for current Camel 2.x users (e.g. just wrap
> the
> 'offending' methods if you don't like them!)??
>
> And I'm really just asking the question here - there's no need for a
> Checked/Unchecked debate. If the Camel community (or just the committers)
> consider the current situation appropriate then I'm perfectly fine with
> that, and I'll just go with the wrapper methods for my systems.
>
> Pat.
>
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Why-do-Camel-core-methods-still-throw-Checked-Exceptions-everyone-agrees-they-re-bad-now-right-tp5732364.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>