[concurrency-interest] Layered exception handling with CompletableFuture

Millies, Sebastian Sebastian.Millies at softwareag.com
Tue Aug 26 18:15:07 EDT 2014


Hello there,

over at comp.lang.java.programmer, Dario Crivelli of lightstreamer.com has made an interesting observation concerning error handling with CompletableFuture.

He said: “[CompletableFuture] views exceptions as some sort of showstoppers, not as special conditions each of which may deserve a different treatment. In fact, it does not allow you to selectively handling some types of exceptions while keeping others for further steps: you can only handle all types of possible exceptions in the same step, perhaps to log an error at the end of the processing” and wonders why this is so.



If you pass futures around in the widespread kind of hierarchical structure, where each layer is responsible for handling certain exceptions, and exceptions may be converted and rethrown (think of data querying exceptions becoming converted to some kind of business logic exception), that may indeed become problematic. Looking at the signatures of

handle<http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html#handle-java.util.function.BiFunction->(BiFunction<http://docs.oracle.com/javase/8/docs/api/java/util/function/BiFunction.html><? super T<http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html>,Throwable<http://docs.oracle.com/javase/8/docs/api/java/lang/Throwable.html>,? extends U> fn)
and
exceptionally<http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html#exceptionally-java.util.function.Function->(Function<http://docs.oracle.com/javase/8/docs/api/java/util/function/Function.html><Throwable<http://docs.oracle.com/javase/8/docs/api/java/lang/Throwable.html>,? extends T<http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html>> fn)
one sees that one gets a catchall clause for Throwables, and that rethrowing is impossible because (Bi)Function#apply() does not throw.

I have not constructed a code example where this might be relevant. Nevertheless, I am passing Dario’s observation to this list, because I’d like to know the reason behind this design decision. I’d welcome any thoughts on this, including wether you believe that it really imposes a relevant restriction, and if so, how one might work around it.

Regards,
Sebastian



Software AG – Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany – Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140826/737f7339/attachment.html>


More information about the Concurrency-interest mailing list