Re: Review of lock-many API [was: svn commit: r1577280 [1/3] ...]
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 27 Mar 2014 13:51:15 +0000 (GMT)
I (Julian Foad) wrote:
Not "should", but rather "could be argued, at some pedantic level".
> but that makes less sense in practice
In fact, I strongly feel we should not return error objects within the results structure. A per-target result is not, in some abstract sense, an error -- the caller didn't try to do something it is forbidden to try, and the server didn't encounter an unexpected condition or anything broken in its execution. A result such as "the lock you're trying to remove is not present" is merely one of the possible and expected outcomes.
The problem existed before this lock-many work. Wrapping the existing design in a multi-target wrapper just exacerbates the issue.
So, rather, we should return flags or other information that specifically states the result for that target. (If a higher level caller wants to consider it an error and construct an error object, that's it's business. For backwards compatibility that will obviously have to be done in some places.)
A different, practical objection to error objects constructed on the server is they are not localized to the client's human language.
This is an archived mail posted to the Subversion Dev mailing list.