Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #29863

Re: Exception Handling in Asynchronous Java Code

Show key headers only | View raw

Am 26.08.2014 21:18, schrieb dario.crivelli@lightstreamer.com:
> Hi Sebastian, my colleague Valerio informed me of your suggestion.
> I acknowledge that CompletableFuture offers a management of exceptions that is more powerful than the native support provided by the Java syntax.
> However, it 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.
>
> This seems to be by design; I don't know the story behind, but I wonder why there is a method
>      CompletableFuture<T> exceptionally(Function<Throwable,? extends T> fn);
> but not something like
>      CompletableFuture<T> exceptionally(Function<Throwable,CompletionStage<T>> fn);
> Am I missing something?
>

Hello Dario,

I took the liberty of passing your question on to the people at 
concurrency-interest@cs.oswego.edu. That is a list well worth watching 
if you're interested in concurrency issues. Here's a link to the 
conversation so far, if you'd like to see what was said:

http://concurrency.markmail.org/search/?q=#query:+page:1+mid:wivv3qnh24y7a4pp+state:results

With regard to the method signatures you posted, I must admit I do not 
understand the second one. Is the idea to somehow compose or nest 
CompletionStages with each other, so that the composition would throw an 
exception when "this" stage completes? I do not see how this is going to 
work with checked exceptions, and you don't need it with 
RuntimeExceptions, just use CF#handle().

A point of more general interest may be that lambdas do not
interact well with checked exceptions. Many people at Oracle and 
involved with OpenJDK now seem to view checked exceptions as a serious 
design mistake in Java.

I remember that exception transparency (making a checked exception 
thrown by a lambda transparently propagate to the surrounding code) was 
originally planned for Project Lambda, but they could not get it to 
work. Brian Goetz once said: "So this is a problem that's best solved at 
the language level (some day), not at the library level."
I fear "some day" here means "never".

Doug Lea has expressed the hope that with Java 8, people will really 
start moving away from using checked exception. In my opinion, however, 
we're always going to be stuck with the exception-throwing stuff in the 
Java libraries itself.

-- Sebastian

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Exception Handling in Asynchronous Java Code valerio.celletti@lightstreamer.com - 2014-07-30 06:49 -0700
  Re: Exception Handling in Asynchronous Java Code Sebastian <news@seyweiler.dyndns.org> - 2014-07-30 17:43 +0200
    Re: Exception Handling in Asynchronous Java Code dario.crivelli@lightstreamer.com - 2014-08-26 12:18 -0700
      Re: Exception Handling in Asynchronous Java Code Sebastian <news@seyweiler.dyndns.org> - 2014-08-27 10:55 +0200
        Re: Exception Handling in Asynchronous Java Code dario.crivelli@lightstreamer.com - 2014-08-27 13:36 -0700

csiph-web