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

Groups > comp.lang.java.programmer > #29440 > unrolled thread

Exception Handling in Asynchronous Java Code

Back to article view | Back to comp.lang.java.programmer

Contents

  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

#29440 — Exception Handling in Asynchronous Java Code

Hi All,

Long time lurker, first time poster. I'd like to point your attention on an article we recently published on our company blog, titled "Exception Handling in Asynchronous Java Code" (link: http://blog.lightstreamer.com/2014/07/exception-handling-in-asynchronous-java.html).

The article explains how to obtain the typical benefits of hierarchical exception handling and static exception checking even for event-driven programming or asynchronous programming. This can be achieved by writing code that follows a specific pattern and leans on a suitable support library. The same technique was applied in some parts of Lightstreamer (which is a real-time data streaming server written in Java) with proficiency.  

I'd like to hear your thoughts and feedbacks on above. What do you think?

Thanks and regards,
Valerio

[toc] | [next] | [standalone]

#29443

Am 30.07.2014 15:49, schrieb valerio.celletti@lightstreamer.com:
> Hi All,
>
> Long time lurker, first time poster. I'd like to point your attention on an article we recently published on our company blog, titled "Exception Handling in Asynchronous Java Code" (link: http://blog.lightstreamer.com/2014/07/exception-handling-in-asynchronous-java.html).
>
> The article explains how to obtain the typical benefits of hierarchical exception handling and static exception checking even for event-driven programming or asynchronous programming. This can be achieved by writing code that follows a specific pattern and leans on a suitable support library. The same technique was applied in some parts of Lightstreamer (which is a real-time data streaming server written in Java) with proficiency.
>
> I'd like to hear your thoughts and feedbacks on above. What do you think?
>
> Thanks and regards,
> Valerio
>

Very nice exposition. I'd like to add that with the advent of Java 8 
there is a base for such frameworks already provided with the JDK, so it 
may be possible to get rid of much of the complexity of your current 
implementation.

Java 8 contains java.util.concurrent.CompletableFuture<T>, a new class 
that represents a CompletionStage of a possibly asynchronous computation 
and provides many ways to bind some function to the result of an 
existing computation. The asynchronous chaining methods will use the 
common ForkJoin pool, otherwise you may provide an executor of your choice.

Especially relevant with regard to the point of your presentation is the 
ability of CompletableFuture to completeExceptionally(), throwing an 
exception when the result of the computation is retrieved from the future.

-- Sebastian

PS: Here's a good intro to CompletableFuture:
http://www.nurkiewicz.com/2013/05/java-8-definitive-guide-to.html

[toc] | [prev] | [next] | [standalone]

#29861

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?

[toc] | [prev] | [next] | [standalone]

#29863

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

[toc] | [prev] | [next] | [standalone]

#29864

Sebastian, Thank you very much.
So, Peter Levart's post, in particular, showed me what I was missing.
Extending "handle" or "exceptionally" is not needed because CompletableFuture manages (unchecked) exceptions thrown by the received functions as a legitimate part of its job; hence, "handle" and "exceptionally" may further propagate an exception that they can't handle by throwing it (in wrapped form).

As a consequence, CompletableFuture does allow for selective handling.
And, of course, all of this is incompatible with checked exceptions, hence, we must give up taking advantage of the compiler checks on different types of exceptions.
I am aware that such checks are useful only in very specific cases. One is when an extension is being made to a working program, and a new special case crops up in some inner part and its handling has to be performed in some outer part.

This compiler check is nothing more than a help; and, in fact, I see checked exceptions as just a syntactic sugar: we could achieve the same information flow and the same level of compiler-granted checks if we handled special cases by leveraging the return types (extending them properly).
For this reason, I can't understand why they are considered such a big problem.
If I understand well, they are not a problem per se, but because the huge base of legacy code that involves checked exceptions is slowing down the evolution of the language in the devised direction.

Dario

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web