[concurrency-interest] More Javadoc problems

Gregg Wonderly gergg at cox.net
Fri Dec 19 17:03:03 EST 2014


Of course, the typical solution is to throw some variant of RuntimeException to subvert the need to have all parts of the API declare the exception chain.  I like checked exceptions, and I really do wish that more people thought about how to document exceptional behavior in their APIs.   Many people seem to believe that there is only “one” way to use there code, and thus believe they have taken care of what needs to be taken care of.

These APIs are largely designed around “computational” activities which just throw RuntimeException for the most part.  The problem is, that “compute only” in the “internet age” is really a short sighted place to be.  All of the I/O necessities in today’s internet application development really requires an Exception path in all cases.  Developers will gripe and complain about it all day long, but once you really have developer, real apps, with I/O, you quickly learn that there are multiple places to deal with exceptions, and many times, at the very top of the call chain is where you need to “abort” the work in progress because that’s the only place that has the database transaction to cancel in view, the calling environment to report an error to, and all the other cleanup knowledge.

Gregg Wonderly

> On Dec 19, 2014, at 3:30 PM, cowwoc <cowwoc at bbs.darktech.org> wrote:
> 
> On 19/12/2014 4:10 PM, Peter Levart wrote:
>> If you want to change the exceptional OR nonexceptional outcome of preceeding stage, then use handle() instead of whenComplete().
> 
> I can't.
> 
> If you handle() and attempt to re-throw the same exception, you will get:
> 
>     unreported exception Throwable; must be caught or declared to be thrown
> 
> I agree that whenComplete() is meant to act as a finally block (which removes the need to do this funky casting). What I don't like is that join() returns without waiting for the result of whenComplete(). If the case of a real try-finally block, the code after the block does not execute after finally completes. I am trying to implement the same behavior here.
> 
> What should I be doing instead?
> 
> Gili
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest




More information about the Concurrency-interest mailing list