Open cenkalti opened 1 year ago
I fix this.
A library should not panic at all.
I don't agree with this statement in this specific context:
Looking at the error list above... most mean that the underlying bbolt file is corrupted or inconsistent. The chances of recovery of such file are big if the file is not subject to continous mutations and the problem will be surfaced soon after the corruption happens.
Moreover panic in golang is not 'terminal'. If the user of the library is determined to continue (e.g. because of hosting multiple instances in a single process), the panic can get explicitly recovered.
To summarise, I recommend:
btesting.go:110: panic("Please call Close() before MustReopen()")
? )I try this in https://github.com/infdahai/bbolt/commit/7d07d9fde19c30a399b445dac2c4fd6a6c077a94. And I agree with @ptabor said. We can replace some panics with error messages, such as panic(fmt.Sprintf("page %d already freed", id))
. But other panics are good indications of the DB crash.
"page %d already freed" is also indicator of either bug in freelist implementation or memory stomping or ram/cpu corruption. It shouldn't happen regardless of bbolt lib user actions.
keeping all code to be consistent around panicking on data inconsistency is easier to maintain
I definitely agree on this. However, I think this should not be the default behavior. Think about these 2 cases:
Panicking takes the whole program down which is not an ideal decision for a library in my opinion.
I propose this:
CorruptionError
to the caller.CorruptionError
wrapping the original error.There is also a special case. Recover only works when called from the same goroutine as the panic is called in. For example:
https://github.com/etcd-io/bbolt/blob/56e033be3380958b4f20b4201d9f77a7d5c029b4/db.go#L1178-L1182
This code block executes when opening a db and it's not possible to recover that panic.
In overall, I see corruption errors as non-fatal. I think it's nicer to let the user decide by returning regular errors.
A library should not panic at all. Panics are usually not handled in Go programs and it makes the whole program crashes when a library function panics.
Currently there are 12 open issues involving panic, especially working with corrupted databases. BoltDB should return the error as an nice message.
Overview of panics from boltdb code: