On Sat, Mar 27, 2021 at 11:12:40PM -0700, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > > > Add a bug() function that works like error() except the message is > > prefixed with "bug:" instead of "error:". > > > > The reason this is needed is for e.g. the fsck code. If we encounter > > what we'd consider a BUG() in the middle of fsck traversal we'd still > > like to try as hard as possible to go past that object and complete > > the fsck, instead of hard dying. A follow-up commit will introduce > > such a use in object-file.c. > > Reading the description above, i.e. "to go past that object", the > assumed use case seems to be to deal with a data error, not a > program bug (which is where we use BUG()---e.g. one helper function > in the fsck code detected that the caller wasn't careful enough to > vet the data it has and called it with incoherent data). If we find > a tree entry whose mode bits implies that the object recorded in the > entry ought to be a blob, and later find out that the object turns > out to be a tree, that is a corrupt repository and the code that > detected is not buggy (and we shouldn't use BUG(), of course). > > So, ... I am skeptical. If the code is prepared to handle breakage, > we would not want to die, but then I am not sure why it has to be > different from error(). Yeah, this seems like it is missing the point of BUG() completely. I took a peek at patch 5/5 of the follow-on, which uses bug(). It looks like it should really be an error() return or similar. The root cause would be open_istream() on a loose object failing (which might be corruption, or might even be a transient OS error!). -Peff
