Sunday, April 06, 2008

Case exhaustiveness for interactivity

In functional programming we're very good at exhaustive case analysis of our data definitions. But I've found I'm pretty bad at reasoning about cases in interactive programs. (Embarrassingly, I recently lost a week's worth of data in an Ajax application I wrote due to a bad response to an unpredicted server failure.)

What are all the possible actions the user could perform? What are all the failure cases? What are all the possible interleavings of interactions? These are harder questions than enumerating variants of a disjoint union.

I think this is where dynamic safety (e.g., runtime tag checking in dynamically typed languages or case-dispatch catchalls in statically typed languages) is so critical: if you don't have a sound model for enumerating the space of possible behaviors, you have to make sure that there's some reasonable recovery programmed into the system for when you encounter an event you didn't predict. This reminds me of recovery-oriented computing and Erlang's "let it fail" philosophy.

2 comments:

Paul Steckler said...

Model-checking helps you identify dangerous execution paths. Perhaps that's too heavyweight for your quick-and-dirty AJAX app, but it's there if you need it.

Stochastic testing a la QuickCheck might be helpful, too.

Then there's always the "this can't happen" branch in your code. :-)

-- Paul

Seafood Recipes said...

This was great to readd