Stefan Sperling wrote on Fri, Dec 23, 2011 at 15:18:05 +0100:
> 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.
Why do we ever set CAN_RETURN to TRUE when calling the handler, then?
Received on 2011-12-24 17:43:32 CET