Re: Errors in p:try/p:catch yield little information when things go wrong

Hi,

Some time ago I patched XMLCalabash to include the whole XProc and XSLT
(and even Java) stack trace in errors. For me it is a huge improvement. I
still haven't tried moving it upstream because I'm not really happy about
how I implemented it. The way it is done now I only get the call stack
information at the point where I *catch* the error. However I would like it
to be such that I get that information when the error is *thrown*. If
someone has a good idea, let me know and I might try it. Anyway, if you are
interested you can have a look at our fork at
https://github.com/daisy/xmlcalabash1/commits/org.daisy.libs. The
interesting bits are in commits a76c163, c3a6e76, 4fa6eff, and da59fc6.

By the way we also have this GH issue:
https://github.com/xproc/3.0-specification/issues/18

Bert


Op vr 24 apr. 2020 om 15:52 schreef David Cramer <david@thingbag.net>:

> On 4/23/20 1:30 AM, David Cramer wrote:
>
> My experience with Calabash is also that it sometimes omits
> interesting parts of error messages. This is particularly the case if
> you run p:xslt. If you run Saxon standalone, you will get much more
> detailed error messages. The messages that Calabash displays are often
> misleading (often some info messages previously emitted by the
> stylesheet, but not the one that comes with the error). This might get
> worse when wrapped in p:try/p:catch. What you report about try/catch
> might or might not be related to the XSLT issue that I mentioned
> (since Calabash uses Saxon’s APIs for almost all lower-level
> operations, it might be related).
>
> There’s already another error about accumulating messages in
> iterations:  https://github.com/ndw/xmlcalabash1/issues/259
> Given Norm’s busy schedule, there is not much hope that he will be
> able to fix it soon. But compared to a couple years ago, Calabash’s
> diagnostic messages have already improved.
>
> I'm less worried about xslts because I can already handle errors inside
> the xslt, write out a helpful report on a secondary port, and terminate
> the pipeline later based what's in that report and after I've
> accumulated all the errors I can reasonably find. To the degree
> possible, I want to avoid forcing the user to run the pipeline, stop on
> the first error, fix that, run it again, stop on the next error, etc.
>
> Actually, you're right about this. I just hit a situation where I'm
> running a 3rd party xslts that sometimes blows up. Refactoring it to handle
> all the errors that might come up would be daunting. It would be much
> easier in xproc.
>
> So there's really just one request: all underlying exceptions, including
> the java stack trace, should be passed on to p:catch in a c:error.
>
> That handles all of these situations.
>
> Regards,
>
> David
>