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: > > > > > > s...@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?
