> -----Original Message-----
> From: Stefan Küng [mailto:tortoisesvn_at_gmail.com]
> Sent: maandag 17 oktober 2011 21:28
> To: Mark Phippard
> Cc: users_at_subversion.apache.org
> Subject: Re: TortoiseSVN exception dialog improvements?
>
> On 17.10.2011 19:46, Mark Phippard wrote:
> > I wonder if the TortoiseSVN team could create a link to a Google
> > search for the error code on the dialog where they ask the user to
> > report the problem? It could ask them to check that link first for
> > other reports of the same problem.
> >
> > That might cut down on the list spam and also get the user an answer
> faster.
>
> I've already removed the email address of the users group from the error
> message, only the link to the web page for the mailing list is still
there.
>
> As you may recall, I've always been opposed to the assert statements. I
> prefer clear error messages and a proper cleanup of resources,
> especially if there _is_ a chance to do so. Maybe now you guys
> understand why.
>
> > Alternatively, maybe we could add some kind of error code lookup URL
> > on our site? Something like:
> >
> > http://subversion.apache.org/errorcode/E235000
> >
> > TortoiseSVN could link user to this URL and our page could direct the
> > user to a wiki page for known errors or a Google search otherwise?
> > When an error becomes really common we could add a wiki page for that
> > code, otherwise just do a search.
> >
> > Just some thoughts.
>
> Since I was repeatedly told that assert statements are only used if
> there's no chance to return an error and clean up the resources, I can't
> use a custom dialog in that case but must rely on the windows own
> message box. Because that's the only dialog that's guaranteed to work
> even in situations where stack and heap are corrupted.
> And that means no clickable links, no buttons to start a browser, ...
assert() is only used in these cases, but this is automatically disabled in
release builds.
In both these reported cases the code calls SVN_ERR_ASSERT() which can
simply return an error code from the handler. See the documentation in
svn_error.h.
Only SVN_ERR_ASSERT_NO_RETURN() has the problems you describe as 'no return
possible', but you get a boolean in the handler to see in which variant you
are.
Another option is to throw a C++ exception and catch it when the call stack
is back in your code. If you then clean the pool you passed to the function
your own code should work reliable again. (You can't be sure that calling
into Subversion is safe, but from what I hear from AnkhSVN users it appears
to just work even though I do recommend them to restart Visual Studio if
this problem occurs)
Bert
Received on 2011-10-18 12:30:13 CEST