Bug 84446 OperationHistory should protect itself better against runtime exceptions
Since clients of the history might rely on getting certain events even if a operation causes runtime exceptions (for example listeners) the history should protect itself better agains runtime exceptions. This envloves: - listeners causing runtime exceptions in the call back - Operation execution causing runtime exceptions. In this case listeners must be informed as well.
bundles/org.eclipse.core.commands/src/org/eclipse/core/commands/operations/DefaultOperationHistory.java
* @see org.eclipse.core.commands.operations.IOperationHistory#execute(org.eclipse.core.commands.operations.IUndoableOperation, org.eclipse.core.runtime.IProgressMonitor, org.eclipse.core.runtime.IAdaptable)
	 */
	public IStatus execute(IUndoableOperation operation, IProgressMonitor monitor, IAdaptable info) throws ExecutionException {
		Assert.isNotNull(operation);
		
		
		if (!operation.canExecute()) {
			return OPERATION_INVALID_STATUS;
		}
		
		/*
		 * If we are in the middle of an open batch, then we will add this operation's contexts
		 * to the open operation rather than add the operation to the history.  We will still
		 * execute it, but will dispose of it afterward.  Operations triggered during an operation
		 * are assumed to be model-related and we assume the undo of this related operation will be
		 * triggered automatically by the undo of the batching operation.
		 */
		boolean merging = false;
		if (fBatchingOperation != null) {
			
			if (fBatchingOperation == operation) {
				return OPERATION_INVALID_STATUS;
			}
			IUndoContext[] contexts = operation.getContexts();
			for (int i = 0; i < contexts.length; i++) {
				fBatchingOperation.addContext(contexts[i]);
			}
			merging = true;
		}
		/*