6

The use-case:

The result: The exception is never caught and there's no tracking/log of it. Which in case of Async systems is 1) undesirable and 2) an indicator for hard and hidden problems (such as NPE, Runtime Exc, etc.) to spot.

The question: Is it feasible to implement CompletableFuture.UncaughtExceptionHandler mechanism by analogy / in a similar manner with java.lang.Thread.UncaughtExceptionHandler? The idea is to provide [default] uncaught exception handler/completion to be called if the CompletableFuture chain does not have java.util.concurrent.CompletableFuture.UniExceptionally Completion attached.

alex.savov
  • 61
  • 2
  • Where do you want to install that handler? – Holger Jan 25 '18 at 16:12
  • @Holger CompletableFuture.set[Default]UncaughtExceptionCompletion by analogy with Thread.set[Default]UncaughtExceptionHandler will be the ultimate solution. Still I'm open for any custom solution that will solve my use-case: prevent CompletableFuture chain from unhandled exception. – alex.savov Jan 25 '18 at 16:28
  • Are you proposing a change of the API? Then, it’s way too narrowly focussed on a particular use case. `CompletableFuture`s are not required to form simple chains; they may have arbitrarily complex dependency graphs. Further, you never know whether someone will add a dependent action that handles exception at some arbitrary later time. Or just call `join()` and handle the exception. – Holger Jan 25 '18 at 16:32
  • @Holger: A custom solution proposed that covers the use-case is good enough. Any idea is appreciated. I just need a default exception completion at the end of the CF chain. – alex.savov Jan 26 '18 at 14:33

1 Answers1

0

The simple answer is: no.

However, someone posted an ugly hack to get similar behavior in another thread: How to handle uncaught exceptions from CompletableFuture.runAsync

I for one escape this problem by using ReactiveX (http://reactivex.io), but that choice might be beyond your control. In that case, you could consider creating a wrapped class for CompletableFuture that always registers an exception handler behind the scenes, so you don't have to explicitely call exceptionally(..) any more. But again, this is just a work-around.

Luzius
  • 41
  • 3