Github user keith-turner commented on the issue:
https://github.com/apache/accumulo/pull/243
> Seems reasonable. Any advantage to using an explicit uncaught exception
handler longer term?
I was thinking about this and did not come to an firm conclusions.
I made some rambling comments on the Jira issue about what I learned while
working on this. If I had only change the ExecutorService calls from
`submit()` to `execute()` then this would have enabled the LoggingRunnable
(created by the NamingThreadFactory) to log the error. However, the users code
calling addsplits would still hang forever. That's why I also changed it to
catch Throwable.
I think in master, this code could be changed to use completable future.
Then the addsplits could wait on that CompletableFuture and it would
automatically handle propagating throwables to the user.
I am not sure, but I suspect we could migrate other code to Future and
CompletableFuture and leverage their abilities to handle exceptions/errors in
other threads. I will try to use CompletableFuture when I merge forward and if
that goes well open a general issue for using it.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
