On Fri, Apr 24, 2015 at 09:16:28AM -0700, Stefan Beller wrote:
> I think it's a mistake to s/Could/could/g for all errors in the code base
> as it reduces the information provided in the error messages.
> Just 3 days ago ("Regular Rebase Failure"). I used different
> capitalization to get a better understanding where the error may be.
>
> So if we throw away that information, we should add new information
> to make the spot of the error easily findable in the source.
> That's why I proposed the idea of the version,filename,linenumber
> as that is one of the strongest signals (most information in a short
> amount of text) I can imagine.
I do like that idea, and I think you could base it on the trace_printf
implementation. Note that it requires variadic macros, but I think
that's OK. Just like trace_printf, we can do the macro implementation
when we support that feature, and people on older systems just won't get
the extra file/line data.
I also assume we would not show this information by default, but only
with GIT_TRACE_ERRORS or something like that.
I would love it if we could also get a stack trace for warnings and
errors. Very often the line number of the error() call is not nearly as
interesting as the line number of the _caller_. But doing that portably
is rather hard. Maybe a better option would be to make it easier to
convince git to dump core at the right moments (e.g., dump core when we
hit die() rather than calling exit). And then you can run gdb on the
core file, which gives you a backtrace and much more.
-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