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). 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).
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.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html