On Mon, 2009-12-21 at 17:38 +0100, Bert Huijben wrote:
>
> > -----Original Message-----
> > From: Julian Foad [mailto:julianfoad_at_btopenworld.com]
> > > Maybe assertions and aborts are easier for Subversion developers, but
> > they are not for our users.
> >
> > That's just stating what happens if there is no user-friendly handling
> > defined. The whole point of SVN_ERR_ASSERT() is to make an internal
> > consistency check brief to code, easy to handle consistently in
> > high-level code (convert them into regular error messages at some place
> > if appropriate) and still certain to be caught (in a crude way - abort)
> > if we forget or choose not to write handler code.
>
> One problem with this is that we convert all assertions to
> SVN_ERR_ASSERTION_FAIL, so we can never convert them to anything more
> detailed without processing the file and line number. Which you can't
> expect any ordinary user will do.
Yes, but assertions check "can't happen" conditions, not conditions that
the user might be able to understand, so a user isn't going to make
sense of such a condition no matter what the message says. In the
example we were looking at, the error is that a txn-id has reached over
200 characters in length. Theoretically, this could happen if the user
has been storing the history of the universe in Subversion for 99
trillion years, but in practice a user will only encounter this error as
a result of a bug in the software.
> So... a buffer index out of range or buffer load assertion
> (libsvn_subr) assertion would have to have the exact same error
> handling as a missing header assertion (serf is full of these).
Right. A user isn't going to understand a buffer index out of range
error in any way that helps them. If the authors of Serf have decided
that a missing header is a "can't happen, fatal error" condition, then
the same applies. (We can argue about whether those conditions have been
correctly classified.)
> Specifying an error code provides more options to our (library)
> users.
Yes, and if there are classes of error that you need/want to handle
differently, that are all presently lumped under SVN_ERR_ASSERTION_FAIL
(or indeed under any other error code), let's discuss them.
Is the Serf "missing header" the one that you are concerned with?
> The only thing we can say for an assertion is: send a mail to
> users_at_subversion.a.o /.t.o. including this piece of information you
> (as user) don't understand. And probably no one at users@ understands
> either.
Users on users@ could reply, "yes, we already reported that to the devs,
and it will be fixed in 1.x.x".
> Currently I ask our users to mail our support list, but I'm happy to
> hardcode the users@ list address for this class of errors if we decide
> to show this unresolvable error in more cases in 1.7...
> Please add useful error messages on all places that a user might
> encounter, likely or unlikely...
> Or even if the webserver sends an incomplete or broken response.
> (Anybody else handled svnbridge errors from Codeplex users?)
Yup, I agree.
Please start a thread to request the Serf "missing header" assertions be
changed to normal errors or warnings or something. (Serf was notorious
for having lots of that sort of thing... often just aborting.)
> Only when an error can't be reached by a normal user an assertion
> could be the correct solution.
Yup, I agree.
- Julian
Received on 2009-12-22 13:36:06 CET