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
* the list of operations available for redo, LIFO
	 */
	private List fRedo = new ArrayList();
	/**
	 * the list of operations available for undo, LIFO
	 */
	private List fUndo = new ArrayList();
	
	/**
	 * an operation that is "absorbing" all other operations while
	 * it is open.  When this is not null, other operations added or
	 * executed are ignored and assumed to be triggered by the batching
	 * 
	 */
	private IUndoableOperation fBatchingOperation = null;
	
	/*
	 * (non-Javadoc)
	 * 
	 * @see org.eclipse.core.commands.operations.IOperationHistory#add(org.eclipse.core.commands.operations.IUndoableOperation)
	 */
	public void add(IUndoableOperation operation) {
		Assert.isNotNull(operation);
		
		/*
		 * If we are in the middle of executing an open batching operation, and this is not that
		 * operation, then we need only add the context of the new operation to the batch.  
		 * The operation itself is disposed since we will never undo or redo it.  We consider
		 * it to be triggered by the batching operation and assume that its undo will be triggered
		 * by the batching operation undo.