This bug exists in all text editors I tried so far, with the exception of iWorks Pages… (they have their own set of issues anyway…)

To recreate the bug:

1. Type text in the text editor really fast. You may even type random text if you’re not such a fast typer…
2. Immediately after, start deleting with backspace
3. Still moving quickly, press ctrl-Z (or command-Z on a Mac) for undo
4. You thought the editor would undo your deletes, right? Hah!

I’ve been kicked by this nasty thing so many times. I type something. ADHD kicks in and I change my mind half way through, starts deleting, changes my mind again and presses cmd-Z. And it undoes everything instead of just the deletes.

Word does this, Scrivner does this… every simple text editor does… apparently 99% of text editor users does the index finger waltz?

Consider the following singleton:

public enum MyVeryImportantSingleton {
  INSTANCE;

  private String a;
  private String b;

  public void set(String a, String b) {
    this.a = Objects.requireNonNull(a);
    this.b = Objects.requireNonNull(b);
  }
}

If it would be called in the following manner:

try {
  MyVeryImportantSingleton.INSTANCE
    .set("Hello world", null);
}
catch (Throwable t) {
  ...all sorts of recovery operations
  ...leaving the system running
}

MyVeryImportantSingleton‘s a-field is set, but the b-field is left in its previous state. This, of course, could turn into really bad news.

The right way to implement set() would be:

public void set(String a, String b) {
Objects.requireNonNull(a);
Objects.requireNonNull(b);
this.a = a;
this.b = b;
}

This is also a great praxis for all form of input error checking. It should first be finished, and then the object state can be updated once all input is ok.

You never know when your method will be called from inside a catch-block by a programmer that, incorrectly assumes the object state is okay even if an exception was thrown.