Re: [PATCH 1/5] usage.c: add a non-fatal bug() function to go with BUG()

> On Thu, May 26 2022, Junio C Hamano wrote:
>
>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>>
>>> I don't think we should do it like that and keep it a BUG() not to call
>>> BUG_if_bug() when we hit exit(), because e.g. in the case of
>>> parse-options.c once we have the a bad "struct options" we don't want to
>>> continue, as we might segfault, or have other bad behavior etc. So we'd
>>> like to BUG() out as soon as possible.
>>
>> Oh, there is no question about that.  When we detect that the
>> program is in an inconsistent and unexpected state, we would want to
>> bug out instead of continuing at some point, and that is why we would
>> want to have BUG_if_bug(), or exit_if_called_bug(), as I called in
>> the message you are reponding to.
>>
>> What I am getting at is that the code often or usually calls
>> BUG_if_bug() is not a reason to require it to be called, especially
>> if there are conditional calls to bug() near the end of the program.
>> Imagine a program, after finishing to respond to the end-user
>> request, before the end of the program, performing some self sanity
>> checks with a series of "if (condition) bug()", and there is no more
>> thing that needs to be done other than exiting after such check.  I
>> would have added such a call to sanity_check_refcnt() at the end of
>> "git blame", for example, if the facility existed.
>
> But you wouldn't want to just stick BUG_if_bug() at the end of those
> sanity checks?
>
> I suppose I can drop the paranoia of requiring it, but since all
> existing callers want to act that way, and I couldn't imagine a case
> where you didn't want that I made it act that way.