generalized catch blocks, now available

Where handler is potentially any expression which evaluates to a
PartialFunction[Throwable, T] where T is the type of the body.

Who's up for a little language change? There's no cost to this: all
current catch blocks would compile exactly as they presently do. If the
catch block isn't a sequence of case statements, then the expression
would be transformed into something like

Although at the moment the only thing I've done is let stable ids work,
so there's no arbitrary expression or lazy evaluation.

Here's a very small demo of some things one might do. If it's not
convincing I can gather convincingness. I think this is the missing
piece for being able to write really appealing reusable exception
handling abstractions.

Where handler is potentially any expression which evaluates to a
PartialFunction[Throwable, T] where T is the type of the body.

Who's up for a little language change? There's no cost to this: all
current catch blocks would compile exactly as they presently do. If the
catch block isn't a sequence of case statements, then the expression
would be transformed into something like

Although at the moment the only thing I've done is let stable ids work,
so there's no arbitrary expression or lazy evaluation.

Here's a very small demo of some things one might do. If it's not
convincing I can gather convincingness. I think this is the missing
piece for being able to write really appealing reusable exception
handling abstractions.

--
Paul Phillips | Simplicity and elegance are unpopular because
Imperfectionist | they require hard work and discipline to achieve
Empiricist | and education to be appreciated.
all hip pupils! | -- Dijkstra