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 <mcbenne...@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. >
