Re: about try/catch

/ James Fuller <james.fuller.2007@gmail.com> was heard to say:
| Perhaps a few words about nested exception handling is in order?

Seems likely :-)

The semantics are intended to work like this: If something goes wrong
in the try, the catch fires. If something goes wrong in the catch, the
try fails.

It follows that a try-catch nested inside the "p:group" of a try will
cause the group to fail if-and-only-if an error occurs in the nested
try-catch's catch.

A try-catch nested inside the "p:catch" of a try will cause the try
to fail if-and-only-if an error occurs in the nested try-catch's
catch.

| 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 don't understand what you mean.

| 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 think a more elaborate error recovery mechanism is unlikely to be
invented for V1.

| 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.

The point of try-catch with respect to the rest of the pipeline is
that it's basically a unit. Both the try part and the catch part produce
the same outputs.

The pipeline processor, threaded or not, has to buffer all the output
of the "try" part before it can continue processing "downstream"
steps.

| 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.

Yes. We were shooting for the simplest thing that could possibly work.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Everything should be made as simple as
http://nwalsh.com/            | possible, but no simpler.