W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > June 2007

about try/catch

From: James Fuller <james.fuller.2007@gmail.com>
Date: Mon, 11 Jun 2007 18:23:58 +0200
Message-ID: <a0ad8ffe0706110923l28ff8704va79e29c5f9dffe5a@mail.gmail.com>
To: public-xml-processing-model-comments@w3.org

Hello,

Exception handling using try/catch has its pros and cons....since we
are not talking about checked exceptions and I believe XProc advocates
a single catch statement  we don't have the issues that creep in with
scalability and versioning that come with  using such things(in java
esp). There are however some unclearness in the spec with respect to
their usage and expected behavior.

For example, when nesting try/catch in the p:group ad infinitum it is
unclear in the spec

e.g. in 4.6 Try/Catch

'A Try/Catch is specified by the p:try element. It isolates a
subpipeline, preventing any errors that arise within it from being
exposed to the rest of the pipeline.'

if a try/catch was nested in a sub pipeline would the errors percolate upwards?

I am assuming no and it would be the current try/catch block that
would activate and go no further. Also what about nesting a try/catch
in the catch block ?

Perhaps a few words about nested exception handling is in order?

also under 4.6 Try/Catch this statement caught my eye.

'In order to ensure that the result of the try is consistent
irrespective of whether the initial subpipeline provides its output or
the recovery subpipeline does, both subpipelines must declare the same
number of outputs with the same names. It is a static error
(err:XS0009) if the p:group and p:catch subpipelines declare different
outputs.'

this is an interesting twist on things but what about the situation
where we want one error handler to handle all declared catches..not an
implausible scenario.

I think that this type of situation, especially within the context of
using the standard core library, could be a common requirement. I
guess its in extension steps, where one would want to handle errors
specifically.

Perhaps you know where this argument is leading...I would prefer to
see a more 'condition exception' based approach to error handling (i
know reusing all the bits in lisp and smalltalk are fashionable these
days), perhaps you could consider declaring an catch-step attribute on
the try? This is syntatic as its easy to just call another pipeline
from the catch....though would have a big impact on verbosity.

Perhaps there are other ways....like getting rid of try/catch all
together and declaring an error-step on p:group?

I guess my main issue with using try/catch is the impact on
performance and the type of coding style it imposes on people....we
have all done the try/catch exercise where we mean to go back later
and fill in the catch to handle the error...worst yet is using this
structure instead of other things like p:choose, which I guess isn't
such a problem with how XProc uses it.

One other issue, which I am unable to verbalise, is what happens if
the XProc application is suspended or we have threads, or parallel
processing occuring...try/catches tend to get a bit messy in these
situations. That being said, I don't think the suspend/restart story
has started yet with XProc.

What I am proposing wont solve bad habits, but I know what typically
happens with try/catch in languages like java, javascript, etc...like
I said at the beginning there are pros as well as cons....used
correctly this approach is a very powerful technique, but I have seen
correct usage to be the, ahem, exception (uggg) rather then the rule.

cheers, Jim Fuller
Received on Monday, 11 June 2007 16:24:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:42 GMT