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

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