Ah, ok. Didn't know about the third argument. I didn't realize that an
int as $error-object would be interpreted as returning that as status
code. Is this documented? I mean how BaseX deals with the third
argument? I couldn't find it. The spec leaves it open to
implementations.
--Marc
On Thu, Aug 13, 2015 at 3:37 PM, Dirk Kirsten <d...@basex.org> wrote:
> Hi Marc,
>
> I agree, I think 500 would be more in line with the HTTP status code
> definitions.. It wasn't really an issue for us in our commercial projects
> ever (as we mostly send custom status code) and I guess this is why no one
> cared/noticed, but it would be cleaner to use 500 by default. By the way,
> you can define the status code easily by using the third argument of the
> error function:
>
> fn:error( xs:QName('error'), "message", 500)
>
> However, as it would be a breaking change it might be wise to delay the
> switch until BaseX 9. Or, of course, there are indeed some reasons why this
> is 400.
>
> Cheers
> Dirk
>
> On 08/13/2015 03:06 PM, Marc van Grootel wrote:
>
> Hi,
>
> 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.
>
> Where is this decided (RESTXQ?) and is there an easy way to change the
> status when fn:error is used?
>
> 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.
>
>
> --
> Dirk Kirsten, BaseX GmbH, http://basexgmbh.de
> |-- Firmensitz: Blarerstrasse 56, 78462 Konstanz
> |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer:
> | Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle
> `-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22
--
--Marc
