> -----Original Message-----
> From: Julian Foad [mailto:julianf...@btopenworld.com]
> Sent: maandag 21 december 2009 16:51
> To: Bert Huijben
> Cc: 'Stefan Sperling'; 'Philip Martin'; 'Mark Phippard';
> dev@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.f...@wandisco.com]
> > > Sent: maandag 21 december 2009 16:05
> > > To: Stefan Sperling
> > > Cc: Philip Martin; Mark Phippard; dev@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 
us...@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
> 


Reply via email to