[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC] Replacement for "assert" in the libraries

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: Fri, 13 Jun 2008 20:32:44 +0200

On 6/13/08, steveking <tortoisesvn_at_gmail.com> wrote:
> David Glasser wrote:
> > I do think that there is value in having a way of assert/aborting from
> > anywhere in the code (not just svn_error_t-returning functions) which
> > can't be ignored accidentally by forgetting to write SVN_ERR and
> > friends. Additionally, assert/abort generally gives good stack traces
> > when run in gdb, whereas it's trickier to track down the source of our
> > error objects.
> >
> I don't know how gdb works. I'm just wondering why an assert/abort helps in
> getting a better stacktrace?
> In windows, if an application causes a segfault, the default windows error
> report dialog shows up and if a debugger is installed on the system, it
> gives you the choice to attach the segfaulting process to that debugger. An
> assert (or worse, an abort) doesn't cause a segfault but only shows a
> messagebox with some pretty useless text (something like "the application
> caused the runtime to close unexpectedly") and no chance of attaching a
> debugger.

On *nix, with gdb, both a segfault and an abort() look very much alike
and both have the effect of ending up in the debugger as you describe.
If you have core dumping turned on, you can even -post-mortem- get a
stack trace to the point of the abort()/assert.

> So for me, the much better way is still to just segfault instead of
> aborting. Of course, even better: returning an error indicating what exactly
> is wrong.

Wouldn't it be more usefull for you to - on Windows - force a segfault
when we in fact really meant an abort/assert()?



To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-13 20:33:13 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.