Errors in the API about badger HOT 11 CLOSED

badger.NewKV("non-existent-dir/foo")

crashes my program. That's not acceptable. Opening a non-existent file is not an internal error, it's a user error which my program will want to relay to the user in an arbitrary way.

from badger.

Besides the pragmatic concerns, it violates go conventions to panic across a package boundary.

from badger.

Yup. Agree with all the concerns here. We have started to surface errors via the API calls (see 31c0bd2). We'll do a sweep over the next couple of weeks over the entire code base. And try to remove all calls to y.Checkf, if possible.

The biggest hurdle would be to deal with background tasks, and we'll need to build mechanisms to deal graciously with them. I'll keep you updated on this thread.

from badger.

We are adding basic checks for the directory to ease usage for the newcomers, see #29.
Overall, we decided that it's library user's responsibility to provide a writable directory for badger for the whole duration of using KV.

There is also a separate thread for disk errors: #28

from badger.

Any operation that could fail, under any conditions, should return an error.

we decided that it's library user's responsibility to provide a writable directory

Sure, you can hope the user provides a writeable directory, but the fact remains that if they give you a directory, and you can't write to it, you need to tell them they failed on their end of the contract.

from badger.

I see that there is a way to get errors when using Entry. Would still be nice to have a version of NewKV that doesn't exit the program.

from badger.

log.Fatals only happen when Badger itself causes issues. External input won't cause it. In fact, these Fatals are really great at catching bugs and making the library robust.

We send errors back when justified, for e.g. when doing CAS operations.

from badger.

I see your point, you are right. We can do much better error handling.

from badger.

Good to hear, looking forward to using the library.

from badger.

See changes: 55c350d and 7610c2f. These surface error handling all the way from disk to public APIs. They should address the concerns raised in this issue.

Closing the issue. Feel free to reopen if some API is still unhandled.

from badger.

Excellent. I will probably switch our usage of BoltDB to Badger, since we are in the early stages of our project as well.

from badger.