Review of solution for Cancelled Tasks

[Tom Eugelink]

I suggested that too (throwing a checked exception name TaskCancelledException), but would required an API change. I was wondering; where did the InterruptedException go in Task? It's the one thing that should be handled AFAIK. And an exception is the only clean way for a thread to clean up its monitors and stuff.

The essence of this problem is a Java one, not a JavaFX one. Even though I like all the ideas, they still seem like a band-aid to me. OTOH, exceptions being thrown is not such a exceptional situation. Suppose the ISE is thrown after the progress values are set. One could get things like:

try
{
     if (isCancelled())
     {
         setProgress(100%) // this throws exception, normally this would be a break or return
     }
     setProgress(counter)
}
finally
{
     cleanup()
}


Or maybe a specialized method that does not throw the ISE xception
     setProgress(100%, false)
     setProgressNoISE(100%)
     setProgressToFinished()

Tom



On 2012-01-05 02:26, Jim Graham wrote:
> 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
>>
>