This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24359 - [FO30] fn:error description lacks information about default arguments
Summary: [FO30] fn:error description lacks information about default arguments
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Proposed Recommendation
Hardware: PC Windows NT
: P2 minor
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-22 14:27 UTC by Abel Braaksma
Modified: 2014-09-15 09:27 UTC (History)
1 user (show)

See Also:


Attachments

Description Abel Braaksma 2014-01-22 14:27:25 UTC
It appeared to me that fn:error [1] lacks a clear description of how omitted arguments are filled.

We currently assume that fn:error(X) means that $description is filled (may be filled) with the error description as defined in the XPath language for that error, if the EQName resolves to an error in either the XPath language spec or in a host language spec. This is in line with raising (known/defined) exceptions in other languages. However, it is also possible that this is not allowed and that $description must be empty in this case.

When the EQName doesn't resolve to a known error, we currently assume $description to be the empty string. Though even in this case, perhaps an implementation can define a predefined value for $description if the error is a known implementation-defined error.

Likewise, for $error-object: is it implementation defined when omitted, or must it be the empty sequence?

I think allowing implementations some freedom for filling $description and $error-object can be beneficial for users.
Comment 1 Abel Braaksma 2014-01-22 14:28:13 UTC
Forgot to add reference to [1]: http://www.w3.org/TR/xpath-functions-30/#func-error
Comment 2 Michael Kay 2014-02-19 08:45:43 UTC
The working group looked at this and decided that although F+O does not clearly describe what happens when no error description or error value are supplied, the rules for XQuery 3.0 try/catch fill this gap, and therefore the problem is not sufficiently severe to justify a spec change before advancing to Recommendation. However, there is scope for better explanation of the situation, so the bug is being reclassified as an editorial bug against 3.1.
Comment 3 Michael Kay 2014-04-29 17:22:22 UTC
This deficiency was accepted on 2014-04-29. The editor has an action to propose the detailed words. The intent is to specify that for arguments left unspecified, e.g. the description and the error object, the value as observed in a catch clause will be implementation dependent.
Comment 4 Michael Kay 2014-04-30 08:59:04 UTC
Proposed change: add the following two rules:

<p diff="add" at="B-bug24359">If no value is supplied for the <code>$description</code>
 argument (that is, if the function is called with less than two arguments), then the
 effective value of the description is <termref def="implementation-dependent"/>.</p>

<p diff="add" at="B-bug24359">If no value is supplied for the <code>$error-object</code> argument (that is, if the function is called with less than three arguments), then the effective value of the error object is <termref def="implementation-dependent"/>.</p>
Comment 5 Michael Kay 2014-05-06 16:57:29 UTC
The proposal in comment #4 was accepted.