Bug 116223 [refactoring] ProcessorBasedRefactoring does not handle exceptions thrown by participants
I20051108-1011 ProcessorBasedRefactoring protects itself against participants that throw an exception in createChange(..). However, it does not catch execptions thrown in initialize(..) or in checkConditions(..). We had a case where initialize(..) threw a ClassCastException, which generated a wrong error message (participant does not extend required type). I think we should protect all call backs and disable participants that throw a RuntimeException.
org.eclipse.ltk.core.refactoring/src/org/eclipse/ltk/core/refactoring/participants/CheckConditionsContext.java
import org.eclipse.core.runtime.IStatus;
import org.eclipse.core.runtime.NullProgressMonitor;
import org.eclipse.core.runtime.OperationCanceledException;
import org.eclipse.core.runtime.Status;
import org.eclipse.core.runtime.SubProgressMonitor;
import org.eclipse.ltk.core.refactoring.IRefactoringCoreStatusCodes;
import org.eclipse.ltk.core.refactoring.RefactoringStatus;
import org.eclipse.ltk.internal.core.refactoring.Messages;
import org.eclipse.ltk.internal.core.refactoring.RefactoringCoreMessages;
import org.eclipse.ltk.internal.core.refactoring.RefactoringCorePlugin;
/**
 * A context that is shared between the refactoring processor and all its
 * associated participants during condition checking.
 * <p>
 * The context manages a set of {@link IConditionChecker}objects to collect
 * condition checks that should be perform across all participants and the
 * processor. For example validating if a file can be changed (see
 * {@link org.eclipse.core.resources.IWorkspace#validateEdit(org.eclipse.core.resources.IFile[], java.lang.Object)}
 * should only be called once for all files modified by the processor and all
 * participants.
 * </p>
 * <p> 
 * Note: this class is not intended to be extended by clients.
 * </p>
 * 
 * @since 3.0
 */
public class CheckConditionsContext {
	
	private Map fCheckers= new HashMap();