Error checking about buntdb HOT 2 CLOSED

Hi Anthony,

As a rule-of-thumb; If a function returns an error, then handle the error. But there are times when I don't check an error, and it's usually one of two reasons:

1. The function can't return an error, even though the function signature has a return value.
2. Failure is optional and sometimes OK, and I often don't care what the error message is.

I'll explain the reason for each of lines you provided:

• https://github.com/muyiwaolurin/buntdb/blob/master/buntdb.go#L349
  The db.Update() call occurs in a background routine and runs once every second until db.Close() is called. Even if db.Update() fails, I still want the routine to continue. An error has no relevance to the decision to stop the background routine. I may want to add logging methods in the future, at which point the error would be useful to write to the logger.
• https://github.com/muyiwaolurin/buntdb/blob/master/buntdb.go#L83
  The error returned from the db.file.Close() call is secondary to the error that was returned by db.load(). I wanted the caller of db.Open() to know why the loading the file database file failed.
• https://github.com/muyiwaolurin/buntdb/blob/master/buntdb.go#L1261
  The type of b is a bytes.Buffer, and bytes.Buffer.WriteString cannot return an error. Under the rare occasion that b.WriteString fails, which can only happen when the application runs out of memory, the function panics and the entire application fails.

This goes for the bufio.Writer.Write() calls too. I ignore all of the errors because an error under-the-hood is likely an out-of-memory situation and will panic the system. The only error I care about is whether or not the data was written to disk. https://github.com/muyiwaolurin/buntdb/blob/master/buntdb.go#L447

I try to handle as many errors as possible, but the truth is some of them just don't matter. I would rather not waste any CPU cycles on those.

I hope this information helps and good luck.

from buntdb.

Thats awesome! Thanks Josh.

from buntdb.