Should we be using expect()?
I'm opening this issue to start a discussion about writing functions that can panic.  I would hope to adopt a no-panic policy, for a more robust codebase.

Commentary:

In my projects I generally avoid use of unwrap/expect -- especially for any code that might possibly be used by other projects... eg anything that might eventually be published on crates.io.

While I might judge it is ok to unexpectedly terminate *my* application, I should not make that choice for other developers.  Instead, its better to define errors with *thiserror* and return them.   The sooner this is done the better, as otherwise a huge pile of code can be written that depends on an API that does not return a Result/Error when it should and changing the huge pile above can be problematic.

Observation:

This project is using expect() in some public fn, such as:

https://github.com/Cuprate/cuprate/blob/59e7e0b4e8daf700b47a6be20a2e3c8a8c68bd74/common/src/pruning.rs#L142

Question:

Is it intended that cuprate, or any sub-components in this repo will be published as a crate for other developers to use?     Or is it intended as end-user application/server?

In both cases I would recommend to get rid of unwrap/expect() wherever possible and instead return Result.   Even if cuprate code is not intended to be used as a library, probably someone will eventually extract some of it for that purpose.    Further, even as a standalone executable, it can be more robust if it recovers from and logs errors rather than panic exiting.

For discussion:

What is, or should be, the cuprate policy with regards to writing and using functions that can panic?

Would we consider:
a) refactoring to get rid of all existing expect(), unwrap(), panic()
b) adding clippy checks to deny expect, unwrap, panic in new code?

btw, I am willing to work on pull-requests for both a and b.