-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change DB interface to return errors #4
Comments
This will be a breaking change. |
tac0turtle
added a commit
that referenced
this issue
Dec 11, 2019
* Return Errors instead of Panicing - closes #28 - closes #4 Return errors and have the application decide how they want to handle panicing :smile Signed-off-by: Marko Baricevic <marbar3778@yahoo.com> * more error changes to prefix and mem dbs * added errors to other dbs and tests pass * linting and testing fixes * add go mod verify to linting * minor cleanup and changes added to cleveldb * return error from Has()` * address some PR comments * some minor touch up on returning errors * remvoe .vscode from .gitignore * error: wraped some errors and comment - add comment about why the error is ignored - wraped a couple of errors with error.Wrap * bring back expect in test case * add error to iterator and reverse iterator * add changelog entry
faddat
referenced
this issue
in notional-labs/tm-db
May 8, 2022
* chore: optimize 2 `[]byte`s concatenation * chore: use `bz2len`
tac0turtle
pushed a commit
that referenced
this issue
Aug 25, 2022
yihuang
added a commit
to yihuang/tm-db
that referenced
this issue
Apr 24, 2023
Problem: pebbledb is not supported
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Low-level libs (db) should not decide whenever to panic or not. It's better to let dbs return an error and handle it in the calling code (say retry N times and maybe panic afterwards).
Pros:
Cons:
The text was updated successfully, but these errors were encountered: