I have to confess that I don't really like this proposal in its current form.
We use a little bit of Typeable magic in SomeException to model an open sum type. It is more or less "just enough" to get us an open set of exceptions on which we can match.
That gives us a nice case analysis construction, we can basically reason type by type and ask if SomeException _is_ a particular data type without losing any information.
Theoretically it means I can give you a nice prism or case handler for it, match on it, rethrow it and nothing is lost.
This proposal gives up a very nice property in exchange for an ad hoc ability to decorate exceptions with anything we want. This strikes me as a short term gain in exchange for giving up a lot of future reasoning power. What is your exception decorated with? Go spend O(n) time rummaging through the list of attached decorations to find out! =/
I'm not offering a concrete worked solution, but there are many other points in this design space. e.g. having a class to let you attach the particular information you want to particular exceptions, having an exception type you can throw with a stack intact that acts as an exception transformer, etc.
None of those require us to give up the simplicity of the open exceptions, but those first two obvious directions have obvious drawbacks, hence why "I'm not offering a concrete worked solution."
Davean's variant narrows the focus down considerably. Limiting it to just the issue at hand, rather than trying to construct a solution to all sorts of problems we haven't even thought of yet. I could get behind something with a more retrenched scope, like that.
That said, I'd very much rather err on the side of doing nothing rather than do the wrong thing here.
We'll be stuck with it for a long time.
-Edward