Closed olurin closed 8 years ago
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:
I'll explain the reason for each of lines you provided:
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.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.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.
Thats awesome! Thanks Josh.
Hi Josh, Nice project. I noticed that you didn't check some errors that are returned from your functions Example:
Is there a reason why you didn't check most errors? (I am trying to learn more about the best practices in Go language)