[whatwg] Exceptions in UndoManager
rniwa at webkit.org
Wed Jul 4 14:42:27 PDT 2012
On Wed, May 30, 2012 at 8:43 AM, Alex Vincent <ajvincent at gmail.com> wrote:
> 1. "What state will the UndoManager be in when an exception happens?"
> There may be transactions that were undone, cropped off by the transact()
> call, which per the spec are now unrecoverable. Also, in the undo or redo
> cases, we might be in the middle of a merged transaction. The spec says we
> can't call undo while we're unapplying a transaction... nor can we call
> redo. So where will we be - both during the event dispatch and in the
> 2. "What information about the exception will be included with the
> event - or with the UndoManager?"
> 3. "If the UndoManager can recover somehow to a known good state
> without intervention, how can it indicate that - and possibly, what that
> good state would look like?"
> 4. "If no recovery is completed, is it acceptable to mark the
> UndoManager in an error state and prevent further transactions from either
> happening or being recorded until both undo and redo stacks have been
> completely cleared?" (I'm thinking of a fatal error state, which can be
> recovered if you throw away all your history.)
> 5. If there is a recovery by one event listener, should another event
> indicating that recovery be dispatched, so that earlier event listeners are
> aware of the new good state?
> I can write up a simple HTML + SVG document illustrating the UndoManager
> Exception cases I can dream up, if anyone's interested. There's four main
> areas: during transact with no undone transactions, during undo where we
> may be in the middle of a transaction group, during redo where we may be in
> the middle of a transaction group, and during transact where some
> transactions have been undone.
> For question 3, I would propose including an UndoManager mockup without
> methods: a static data representation of the default after-state. Note
> that it is perfectly okay in my opinion for the UndoManager to report "I
> cannot recover from this on my own," and not provide this mockup at all.
For point 1, we should move step 2 (clear all redo) in the definition of
transact() to after step 3.
Points 2 and 5 makes me think that we should just propagate the exception
instead of firing an event. Whoever is catching the exception can take
appropriate actions then.
I don't understand what you mean in point 3.
What's the use case for point 4.
In general, I don't want to make the spec too complicated. I want to
provide the simplest API that gets job done. If there are some use cases
that require elaborate exception handling, then I would like to let
scripts/libraries provide such an API instead of baking it natively into
the spec. Of course, the native UndoManager should be flexible enough to
accommodate such needs.
More information about the whatwg