[cdt-dev] IProgressMonitor - canceling operations

[Chris Wiebe <cwiebe@xxxxxxx>]

Hey everybody,

I'd like to stimulate some discussion as to the best approach to deal 
with a user canceling a long-running operation in CDT 2.0   In 
particular I was recently stung by an uncaught OperationCanceledException:

  https://bugs.eclipse.org/bugs/show_bug.cgi?id=51250

As a policy for CDT 2.0 and beyond, I propose that UI code should throw 
InterruptedException rather than OperationCanceledException in response 
to a user canceling a progress dialog.

To quote from _Contributing to Eclipse_ (Gamma & Beck, p.188):

    To find out whether a user has requested a cancellation, the
  operation should call [IProgressMonitor] isCanceled() frequently   If
  the user requests a cancellation, the operation should be terminated
  by throwing an exception   The exception can be either an
  InterruptedException or an OperationCanceledException   We prefer
  InterruptedException because wherever possible you want to reuse
  existing types rather than introduce your own.
  (OperationCanceledException is still supported for backwards
  compatibility)   This is a snippet you will find in many Eclipse
  operations:

    if (monitor.isCanceled())
      throw new InterruptedException();

Operations should be encapsulated inside the invocation method, as in 
this example build() operation (Gamma & Beck, p.189):

  protected boolean build() {
    ProgressMonitorDialog dialog= new ProgressMonitorDialog(
      getShell());
   try {
      dialog.run(true, true, new IRunnableWithProgress() {
        public void run(IProgressMonitor monitor)
          throws InvocationTargetException {
            // invoke build
        }
      });
    } catch (InterruptedException e) {
      return false;
    } catch (InvocationTargetException e) {
      Throwable target= e.getTargetException();
      //TODO inform about target exception
      return false;
    }
    return true;
  }

My main beef with the OperationCanceledException is that it is a 
RuntimeException and so does not have to be declared with a throws 
clause and can thus slip through without being caught   As a policy, 
RuntimeExceptions should be used sparingly, to indicate programming 
errors (ArrayOutofBounds, etc.) and not to indicate a normal and 
perfectly valid state of affairs (user clicked the cancel button).

Thoughts?

-Chris