This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Within the catch() of a try-catch expression [1] available various error details are made available as variables e.g. $err:code. As a XQuery developer I want to use common error logging/handling routines across an application or applications. It is tedious to pass all the error details into such a common function. Now maps are part of XQuery, I would find useful a function something like declare function err:details() as map(*) Within the catch expression it would return the value of map{ "code":$err:code, "description":$err:description, "value":$err:value, "module":$err:module, "line-number":$err:line-number, "column-number":$err:column-number, "additional":$err:additional } An example use would look like: try{ ... } catch * { myerrorhandler( err:details() ) } /Andy [1] http://www.w3.org/TR/xquery-31/#id-try-catch
I like the idea. Maybe an additional variable ($err:details ?) could be added to the catch scope, which contains the map you proposed.
A variable would be fine for me.
Not denying that this is a good idea, but we're way past the time for putting things in to the spec just because they are good ideas.
Note that at some point with XP30 maps were suggested and approved. Later they were dropped because maps were not ready for inclusion yet (this is why XSLT and XQuery have the same here, even XSLT has withstood the temptation to turn the errors into a map, notwithstanding positive support for it). Maps have now made it to XP31, whether that means you need an *extra* way of getting the data of an error, I don't know. If I had the chance, I'd drop the error vars entirely, a scoped function like current-group() in XSLT but then current-error() with similar semantics sounds way better, but I'm with Michael here, I believe we're past our window for new ideas...
(In reply to Michael Kay from comment #3) > Not denying that this is a good idea, but we're way past the time for > putting things in to the spec just because they are good ideas. Agreed.
Good idea, too late in the game.