Re: Catching errors

/ Rui Lopes <rlopes@di.fc.ul.pt> was heard to say:
| I'd like to propose a more flexible way to handle errors, in comparison to the
| status quo.
|
| My proposal is a small addition to the p:catch element: an optional @code
| attribute with the same semantics of p:error's code option. This would allow a
| pipeline author to catch just a specific error, instead of catching any error,
| handling it appropriately in situ. Other errors would be caught by outer
| p:try/p:catch blocks.

This is almost just syntactic sugar for a p:choose inside a p:catch.
What's different is that it would allow "other errors" to percolate
up. We have no mechanism for doing that.

I don't know. Someone's going to suggest p:finally if we do this.
(Actually, it's already been suggested to me, but...)

| On a side note, should we define error codes for each step (both required and
| optional ones), or leave it as implementation defined? I think it would be
| somewhat verbose to describe them (e.g., all errors for XSLT 2.0), but it would
| provide us a thinner control of pipelines -
| and interoperable - using my @code proposal.

We should probably define codes for the "obvious" errors in our
standard components. I don't think we want to enumerate all the
possible user errors though (e.g., all the things that can go wrong in
an XSLT stylesheet).

| Thoughts?

I'm on the fence. We have to draw the line somewhere.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | If man were never to fade away like the
http://nwalsh.com/            | dews of Adashino, never to vanish like
                              | the smoke over Toribeyama, but lingered
                              | on forever in the world, how things
                              | would lose their power to move us! The
                              | most precious thing in life is its
                              | uncertainty.--Yoshida Kenko