Hi Peff,
On Thu, 30 Jun 2016, Jeff King wrote:
> On Thu, Jun 30, 2016 at 10:42:37AM +0200, Johannes Schindelin wrote:
>
> > > > The vast majority of error messages in Git's source code which report a
> > > > bug use the convention to prefix the message with "BUG:".
> > >
> > > Good thing to do.
> > >
> > > But if we were to review and apply a 200+ line patch, I wonder if we
> > > want to go one step further to allow us to write
> > >
> > > BUG("killed-file %s not found", name);
> > >
> > > instead.
> >
> > If the idea is to make it easier to find, I would wager a guess that
> > 'die("BUG:' would be just as good a search term. Even better, I think,
> > because 'BUG' would also match comments.
>
> I have been tempted to switch to BUG(), because it would make it easy to
> call abort() and get a coredump (and therefore a stack trace).
Please keep in mind that abort() does not produce stackdumps with MinGW.
So at least Windows developers would not be better off.
> On the other hand:
>
> - we could always trigger such behavior in die() by looking for "BUG:" in
> the output string. :)
>
> - it's also sometimes useful to get a stack trace from a regular
> non-bug die(). So maybe something optional like:
>
> if (git_env_bool("GIT_ABORT_ON_DIE", 0))
> abort();
>
> would be helpful (since you have to turn it on ahead of time, you
> could also just run the program under gdb, of course; however, I
> sometimes find that it's hard to get gdb where you want it because
> git spawns so many sub-programs. Or maybe I just need to get better
> at using gdb's child-following options).
Heh. I still find myself using that good old trick where I set a variable,
loop while it is set and print out the pid, waiting for a debugger to
attach and re-set that variable.
> The other thing BUG() would get us is that we could turn it into a macro
> (on systems with vararg macros) and report things like __FILE__ and
> __LINE__. In practice, though our BUG messages are unique enough that
> there is no problem finding the source.
That would be very nice *also* for error() messages. But I guess we cannot
have it, vararg macros being a feature rather than a standard.
Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html