Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] IProgressMonitor - canceling operations

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:

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

    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(
   try {, 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).



Back to the top