On Fri, Dec 23, 2011 at 04:10:07PM +0200, Daniel Shahaf wrote:
> On Fri, Dec 23, 2011, at 14:50, Stefan Sperling wrote:
> > On Fri, Dec 23, 2011 at 02:26:40PM +0200, Daniel Shahaf wrote:
> > > On Fri, Dec 23, 2011, at 13:01, Stefan Sperling wrote:
> > > > On Fri, Dec 23, 2011 at 01:48:18PM +0200, Daniel Shahaf wrote:
> > > > > stsp_at_apache.org wrote on Fri, Dec 23, 2011 at 00:35:16 -0000:
> > > > > > + An informative error message helps people more than an assert (which
> > > > > > + in case of TSVN can mean crashing the Windows Explorer).
> > > > >
> > > > > I thought the svn_error_malfunction_handler_t stuff addressed that issue?
> > > >
> > > > No, because TSVN didn't end up using it as intended.
> > > > See bottom of http://svn.haxx.se/users/archive-2011-10/0378.shtml
> > >
> > > I don't see how that's relevant? That link discusses the error dialogs.
> > > What I'm asking is whether TSVN has implemented an
> > > svn_error_malfunction_handler_t that replaces the default handler,
> > > svn_error_abort_on_malfunction().
> >
> > Yes it does (called svn_error_handle_malfunction()) but it calls abort()
> > which means the explorer crashes:
> > http://tortoisesvn.googlecode.com/svn/trunk/src/SVN/SVN.cpp
>
> And they can't remove the abort() call because...?
As Stefan explained, he cannot rely on the internal state of the
application if he gets an assertion thrown out of the svn libraries.
And he has a point. He assumes that asserts are fatal and non-recoverable
errors. What if Subversion asserts because it just trashed the entire
stack and heap space of the windows explorer and happens to operate on
garbaga data that triggers an assertion? It doesn't make any sense to try
to continue.
Now, we know that most of our assertions are due to bugs in our code
where, for instance, invalid data entered wc.db. But an application
using the svn libraries cannot safely rely on this knowledge.
Changing all these bogus asserts that trigger just because of invalid
working copy meta-data into proper errors is the right way to fix this.
Received on 2011-12-23 15:18:39 CET