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

On 4/22/20 2:41 AM, Imsieke, Gerrit, le-tex wrote:

> Hi David,
> On 22.04.2020 06:48, wrote:
>> Greetings,
>> I'm using p:load to load a doc and wrap it in a p:try/p:catch in
>> XProc (Calabash 1.22). When the document is malformed or unparsable,
>> I get very little information about the nature of the problem in the
>> catch:
>> <c:errors xmlns:c="">
>>      <c:error xmlns:err=""
>> code="err:XC0011"
>>          href="file:/path/to/pdf.xpl"
>>          line="6" column="65">Could not load
>>          /path/to/Quinoa_Axe_Throwing_Specification.xml
>>          (file:/path/to/pdf.xpl)
>>          dtd-validate=false</c:error>
>> </c:errors>
> This error message is probably already as detailed as it gets, given
> that a program that uses an XML parser API does not see any difference
> whether the file is malformed or non-existent.

It would be super useful if I could tell them whether the parsing of the
file failed because of an unresolved entity and an unclosed tag. The
parser certainly knows that--it shows up in the "Underlying exception"
in the stack trace: "lineNumber: 9; columnNumber: 55; The entity "foo"
was referenced, but not declared". Couldn't the xproc parser put that
stack trace in a c:error and let me deal with it? After all, I'm using a
try/catch because I want to catch exceptions. If Calabash catches one
from the parser, it can just throw it to me in the pipeline. I'll open a
ticket against Calabash about that.

>> Likewise, when I wrap p:include in a try/catch, I only get an error
>> code indicating that it couldn't load a file and line numbers in the
>> xpl:
>> <c:error href="file:/path/to/library.xpl" line="18" column="34">XProc
>> error err:XD0011</c:error>
> That’s another story. I agree that the message should contain all the
> information that you see without try/catch.
> I filed an issue:
Thanks for doing that. Due to the recursive nature of xincludes, it's
important to give the user a clue about what file it was trying to open.
>> There's no information about which file or files couldn't be loaded
>> for example.
>> I was attempting to have the pipeline package up the error
>> information about why things fail and report it in a friendly way to
>> my users. If I were to load the same document as the source for the
>> pipeline and not use try/catch, Calabash would give me more
>> information about why it failed to parse the document, which xinclude
>> couldn't be resolved, etc but when I do that I have no way to recover
>> gracefully from a failure within the pipeline.
>> Am I going about things the wrong way? It seems that I have to put
>> this code in the layer that calls Calabash and scrape the
>> unstructured stderr/stdout info to let the user know what went wrong.
> 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:
> 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.
> You might try Achim’s processor, Morgana XProc, either in the XProc
> 1.0 or in the XProc 3.0 beta version.
> Morgana has had more detailed error messages for quite some time.
> Both implementors, in particular Norm, have pledged to make error
> messages (more) user friendly in the XProc 3.0 versions of their
> processors.

Thanks, I'll experiment with Morgana. Looking forward to XProc 3.0!



Received on Thursday, 23 April 2020 06:31:01 UTC