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#addOperationHistoryListener(org.eclipse.core.commands.operations.IOperationHistoryListener)
	 */
	public void addOperationHistoryListener(IOperationHistoryListener listener) {
		fListeners.add(listener);
	}
	/*
	 * (non-Javadoc)
	 * 
	 * @see org.eclipse.core.commands.operations.IOperationHistory#canRedo(org.eclipse.core.commands.operations.IUndoContext)
	 */
	public boolean canRedo(IUndoContext context) {
		
		IUndoableOperation operation = getRedoOperation(context);
		return (operation != null && operation.canRedo());
	}
	/*
	 * (non-Javadoc)
	 * 
	 * @see org.eclipse.core.commands.operations.IOperationHistory#canUndo(org.eclipse.core.commands.operations.IUndoContext)
	 */
	public boolean canUndo(IUndoContext context) {
		
		IUndoableOperation operation = getUndoOperation(context);
		return (operation != null && operation.canUndo());
	}
	/**
	 * Check the redo limit before adding an operation.  In theory the redo limit
	 * should never be reached, because the redo items are transferred from the undo
	 * history, which has the same limit.  The redo history is cleared whenever a new
	 * operation is added.  We check for completeness since implementations may change