29264 2015-11-06 10:48:43 +0000 [XQ31] XQuery err details as a map 2015-11-10 17:27:40 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3.1 Working drafts PC Windows NT RESOLVED WONTFIX P2 normal --- 1 andybuncester jonathan.robie abel.braaksma christian.gruen mike public-qt-comments oldest_to_newest 124110 0 andybuncester 2015-11-06 10:48:43 +0000 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 124115 1 christian.gruen 2015-11-06 15:12:03 +0000 I like the idea. Maybe an additional variable ($err:details ?) could be added to the catch scope, which contains the map you proposed. 124116 2 andybuncester 2015-11-06 15:17:56 +0000 A variable would be fine for me. 124117 3 mike 2015-11-06 15:29:34 +0000 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. 124120 4 abel.braaksma 2015-11-06 17:02:37 +0000 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... 124121 5 abel.braaksma 2015-11-06 17:02:46 +0000 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... 124142 6 jonathan.robie 2015-11-09 21:07:42 +0000 (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. 124159 7 jonathan.robie 2015-11-10 17:27:40 +0000 Good idea, too late in the game.