RE: svn commit: r884250 - /subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c

> -----Original Message-----
> From: Julian Foad [mailto:julianfoad_at_btopenworld.com]
> Sent: maandag 21 december 2009 16:51
> To: Bert Huijben
> Cc: 'Stefan Sperling'; 'Philip Martin'; 'Mark Phippard';
> dev_at_subversion.apache.org
> Subject: RE: svn commit: r884250 -
> /subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c
>
> Bert Huijben wrote:
> >
> > > -----Original Message-----
> > > From: Julian Foad [mailto:julian.foad_at_wandisco.com]
> > > Sent: maandag 21 december 2009 16:05
> > > To: Stefan Sperling
> > > Cc: Philip Martin; Mark Phippard; dev_at_subversion.apache.org
> > > Subject: Re: svn commit: r884250 -
> > > /subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c
> > >
> > > Stefan Sperling wrote:
 
> > 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.

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). Specifying an error code provides more options to our (library) users.

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.

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?)

Only when an error can't be reached by a normal user an assertion could be the correct solution.

        Bert
>
> - Julian
>
Received on 2009-12-21 17:39:00 CET