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


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

Re: Exception Handling in Asynchronous Java Code

Newsgroups comp.lang.java.programmer
Date 2014-08-27 13:36 -0700
References <2e594246-2475-4b45-ae5e-2624b9a843d1@googlegroups.com> <lrb3rl$2m3$1@news.albasani.net> <2600676e-aa05-41fa-9540-e3a1f83ea600@googlegroups.com> <ltk6df$k23$1@news.albasani.net>
Message-ID <9411acf6-4ae7-4950-8e3f-5b40b47ace28@googlegroups.com> (permalink)
Subject Re: Exception Handling in Asynchronous Java Code
From dario.crivelli@lightstreamer.com

Show all headers | View raw


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

Back to comp.lang.java.programmer | Previous | Next — Previous 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