Review of solution for Cancelled Tasks

[Jim Graham]

This was the original reason behind checked exceptions.  IO operations 
were the main target because they are the thing that most threads end up 
in when they really should have been cancelled - and also because those 
methods are blocking and we needed an exceptional return value.

Simply declaring updateProgress() and some other key methods to declare 
that they throw Interrupted will mean that the developer will be forced 
to opt in by virtue of having to catch the exception.

It's worked reasonably well for Java I/O for a while, though I'll admit 
it is an annoyance for programmers - but it is a healthy annoyance...

			...jim

On 1/4/2012 11:39 AM, Jeff Martin wrote:
> Another idea might be to throw the InterruptedException from a method called fireInterruptedException(), so savy rollback Tasks could override it to do nothing.
>
> jeff
>
>
> On Jan 4, 2012, at 1:24 PM, steve.x.northover at oracle.com wrote:
>
>> One (wild/bogus/too late?) idea might be to combine checking for cancel with progress update.  That way, programmer can't do one without the other.
>>
>> Steve
>>
>> On 04/01/2012 2:11 PM, Richard Bair wrote:
>>> Ya, that was exactly what I was proposing :-). If the updateXXX methods throw an ISE when called from a background thread of a cancelled task, then you will generally get the behavior you instinctively want -- the thread dies (most of the time) and the thing stops getting updated.
>>>
>>> However this means that when you actually DO want to update the progress, message, or title when the thing is cancelled, then you need to do it in the cancelled() method (which is called on the FX app thread) or you have to use a Platform.runLater() if you handle it from the call() method.
>>>
>>> So throwing the exceptions will cause some exceptions in existing apps that weren't happening before (although maybe that is good since it will, if left unhandled, kill the thread). It will make it more difficult for people who are wanting to update the title / message / progress after the thing is cancelled.
>>>
>>> In either case all use cases are possible, it is just a matter of which you bias for. Do you bias for the naive implementation or the sophisticated implementation? Generally I always bias for the naive implementation because even great developers are happier when things "just work" the way their intuition dictates and the exceptions give enough context that developers who want to do the advanced stuff can determine how it is done.
>>>
>>> Richard
>>>
>>>
>>> On Jan 4, 2012, at 11:05 AM, steve.x.northover at oracle.com wrote:
>>>
>>>> Hmmm .. perhaps they should throw an exception, not update the progress and not cancel nicely?  I suppose that this "cancels" the task!
>>>>
>>>> Steve
>