TexShop will not compile without trashing aux files after every error

Although there is already an answer to this question, I think it is wrong. TeXShop users are always complaining about this problem and hardly any other people are complaining. I've been a TeXShop fan almost since the first edition but this is its most annoying feature. It happens to me all the time in TeXShop and almost never in any other program I use, including manual command line execution.

The reason it happens is something to do with the state TeXShop leaves the aux file in when typesetting is aborted at an error. That is, if compilation stops at an error, then you fix the error and hit compile again, latex sees a bad aux file. To see that it isn't (usually) your latex error that caused the bad aux file, instead of starting the compilation again immediately, enter "x" into the window at the bottom of the console window to make latex continue to the end regardless of errors. Now fixing the error and compiling again will usually work.

As several people noted above, deleting the aux file automatically is a bad idea. What should happen (though I don't know how to automate it) is that the aux file is deleted if it wasn't written completely.

This is the nature of the beast...

TeX employs an (external) auxiliary .aux file to store information at/of every run. This file is used extensively when dealing with labels and references (see Understanding how references and labels work) since the output routine only flushes pages after having collected enough content to fill it (and perhaps more). As is evident from your error snippet, it deals with an offending \label usage.

Here's the sequence that causes the error:

1. You compile your document.
2. \label-information is stored in .aux. This information will be read during a subsequent compilation. If problematic code is written to the .aux, you will only pick it up in this subsequent run. However, this run itself may compile without problem.
3. You compile your document again in order to make sure the references settle. However, now the problematic code is read in, causing the error.

Note that, even during the second compile (item 3 above) you are still writing problematic code to the .aux. So, even if you fix it and recompile, the problem will still show in the subsequent compile.

Some problems are recoverable, but others are fatal, depending on when you are writing the information to the .aux. In a worst-case scenario - when the problem persists even though you've fixed your code - delete the offending .aux and recompile (at least twice).

_{How do you avoid this annoying extra step? Don't make mistakes... :) Well, at least not when dealing with content written to the .aux file.}