Hi Marc,
Nothing major but I was wondering what the thinking was behind returning a 400 when fn:error is raised. Basically that says "client, your mistake not mine" where in most cases I guess a 500 would be more appropriate.
The rationale behind this was that a RESTXQ developer can use fn:error functions, which are triggered when the client sends invalid input. But it's true that 500 codes may be more appropriate if the server code is buggy indeed.
Unfortunately, it's not really possible to detect if an error was explicitly raised in the XQuery code, or if it was unexpected. Errors starting with XPST usually indicate parsing errors, but even those codes can be manually generated:
fn:error(xs:QName('err:XPST0003'), 'Hehe')
Of course I can always catch at the highest level and then decide which HTTP status to return but I'm not sure if I want to wrap all REST calls in try / catch.
Could you write more about your use case? Do you expect your code to be buggy, or when do errors occur?
Christian
PS: Dirk may give you another reply on the third argument of fn:error. I'm not sure if it really works (but never forget I'm getting older every day ;)