John Snelson wrote: Hi John,
> The error handler is only invoked if the query terminates by raising > an (XQuery) error. Otherwise the result of the query is returned, > even if the HTTP response code is classified as an error response. Ok, thanks. So a couple of comments then: 1/ The App Dev Guide should be changed from "When any 400 or 500 HTTP exception is thrown" to "When any XPath error is thrown". The current wording let me think I could tell from the "normal" code what kind of error was launched, by setting the HTTP return code AND calling fn:error(). But regardless to whatever HTTP code I set, I always get a 500 in the error handler when calling fn:error(). 2/ The external variable $error:errors is automatically bound to a description of the error thrown by fn:error(). Including the user error objects (fn:error() 3d param). Good, that gives me a way to define a flexible and generic error handler in my application, by giving the opportunity to pass info to the error handler from the "normal" code. But wait... It looks like only the string value of each of the error objects is included in $error:errors! That makes it really less useful... Is it really intended, or is it a bug? If it is intended, is there any other way to pass structured info from "normal" code to the error handler (other than text parsing)? Thanks for your response! Regards, -- Florent Georges http://fgeorges.org/ http://h2oconsulting.be/ _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
