camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ferraro <>
Subject Re: Camel 3.0 ideas: Remove throws Exception from API signatures and use unchecked exceptions
Date Thu, 27 Oct 2016 10:37:58 GMT
My 2 cents.

A fake "throws Exception" put in place "for future usage" can be removed
IMO. But turning an exception into a RuntimeException may affect a route
behaviour if the Camel API you're talking about is available for the end
users in DSL (eg. error handling policies).

So, we should analyze it case by case.

On the other hand, I see that some functional transformations (eg.
can also accept a checked function or supplier.

I mean, we can solve the problem almost like the Javaslang guys did
(greatly !) for the Java collections:

On Wed, Oct 26, 2016 at 6:47 PM, Antonin Stefanutti <>

> Hi,
> Would you think that makes sense to remove the 'throws Exception' from a
> number of Camel API signatures as well as using unchecked exceptions
> instead?
> While this may be a matter of opinion still debated, there are a couple
> resources that gives some guidelines on the topic and that may help
> answering that question:
> - "How to Design a Good API and Why it Matters" presentation and
> "Effective Java" from Joshua Bloch
> -
> exceptions/runtime.html
> I raise the question as I've encountered yet another case where checked
> exceptions fail to deliver on their promises, that is with functional
> interfaces (stream, lambda, ...) introduced in Java 8. There is a lot of
> resources out there describing the problem in details:
> -
> throw-checked-exceptions-from-inside-java-8-streams.
> -
> javas-biggest-mistake/
> Hence the question. WDYT?
> Antonin

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message