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.
