Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!us.feeder.erje.net!news2.arglkargh.de!news.albasani.net!.POSTED!not-for-mail From: Sebastian Newsgroups: comp.lang.java.programmer Subject: Re: Exception Handling in Asynchronous Java Code Date: Wed, 27 Aug 2014 10:55:11 +0200 Organization: albasani.net Lines: 53 Message-ID: References: <2e594246-2475-4b45-ae5e-2624b9a843d1@googlegroups.com> <2600676e-aa05-41fa-9540-e3a1f83ea600@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net ukRzGfhRIXOxvxPch+ErtSr4vk1kKvcV9cMhw1bQZj/bRVy0HdJnhR3J8ZbhK80w0G8mDvBCoNIaZX8hbFhTsRTHPufoBJzbX5f3ZFrp3BnMuOcqVH8k78HAnG7Xtn9W NNTP-Posting-Date: Wed, 27 Aug 2014 08:55:11 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="tDp0X56LjWCi9bA9VHtb6lamm2pd9F6Z/RLVYhtAOkpbNMtb0lv08q/l7ulMqtY4ZCwOzf5bY29zsOVFlCHkeodD015U1p3RIedGgtkDwIVadz4TX0zxOLWmjRndO7Zm"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 In-Reply-To: <2600676e-aa05-41fa-9540-e3a1f83ea600@googlegroups.com> Cancel-Lock: sha1:RluQVOG6xuDCXHUDkBWYhfgDFOU= Xref: csiph.com comp.lang.java.programmer: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 exceptionally(Function fn); > but not something like > CompletableFuture exceptionally(Function> 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