#error recovery

[brrian]

Sometimes, the code you have isn't the code you wish you had. This is especially true when doing static analyses, or interactive, incremental compilation in an IDE setting. As it turns out, most code does not parse or typecheck when it is being edited.

The PPA project (published at OOPSLA 2008; pdf; ACM) describes a number of semantic "guesses" to infer/recover a partial program's types. In this work, the focus is on recovering types from one file torn asunder from a repository. It is implemented with Soot and Polyglot. It could obviously be extended to handle single or multiple methods disconnected from their class. I think this work would be great inside of an IDE, when most of the point of online compiler feedback is to keep fresh information for code search (which is already imprecise), or simple syntax-based code highlighting.

[doitalex]

The core skill of innovators is error recovery, not failure avoidance.

Randy Nelson, former President of Pixar University

[guillermonkey-blog]

The major difference between a thing that *might* go wrong and a thing that *cannot possibly* go wrong is that, when a thing that cannot possibly go wrong goes wrong, it usually turns out to be impossible to get at or repair.

Douglas Adams [Hitchhiker's Guide to the Galaxy]

[guillermonkey-blog]

The primary duty of an exception handler is to get the error out of the lap of the programmer and into the surprised face of the user. Provided you keep this cardinal rule in mind, you can't go far wrong.

Verity Stob

[guillermonkey-blog]

I remarked to Dennis [Ritchie] that easily half the code I was writing in Multics was error recovery code. He said, «We left all that stuff out [of Unix]. If there's an error, we have this routine called panic, and when it is called, the machine crashes, and you holler down the hall: Hey, reboot it.»

[Tom Van Vleck](http://www.multicians.org/unix.html)