Improve debugging by adding error contexts
eozturk1 opened this issue · comments
We have errors that only include the error string in the error. When these errors surface up, they don't have any context on where and why they occurred (e.g., a MySQL error). We should improve these by adding
- More context to the errors, e.g.,
GetDataerror inbatch_getshould mention that the operation was batch get. - Stack trace info. --> Since the stack trace leading to the error is cleared up when the error is caught, we lose this info.
- Line numbers and file names when the error occurred.
A good point to check into on this might be the log crate, there is already a capturing which occurs with each macro call (e.g. debug!(...)) that is capturing a lot of this information. You can check our own log implementations, but we're capturing exactly this kind of info (file, line, thread, etc).
Might be a good starting point to populating this error metadata
The logs by the log crate are not displayed (except println!). We need a logger implementation (@afterdusk pointed this out!) in addition to the log crate -- maybe env_logger. And initialize it. Then we can get those logs.
Ah I meant looking at how they capture the file, line number, method, etc. Not actually relying on it, sorry!
So I think logging is going to be the way to go here. I was looking into how this would be implemented, but we would need to redefine the error structures we pass around to also collect a "context" object and when an error is to be returned, append the context about module,line,file,etc. This means modifying every location where an error response is generated, and kind of goes against the "spirit" of Rust's Result<_,_> type (from what I'm reading).
We can do it, but I think utilizing the log crate more heavily is going to make more sense here. I did do a large cleanup of the error types and how they're propagated around to make more sense of them, but no context as of yet.
Yeah, +1 on using the log crate. With proper context and unique error messages, we don't need the file/line to be included. I guess the initial issue we should focus on is actually getting the logs using env_logger. Otherwise, if they aren't println! I can't see any logs.
Yeah, +1 on using the log crate. With proper context and unique error messages, we don't need the file/line to be included. I guess the initial issue we should focus on is actually getting the logs using env_logger. Otherwise, if they aren't
println!I can't see any logs.
Qq: Where are you seeing or not-seeing the logs? What are you looking at for log messages? The unit tests I guess? We might need to write a wrapper to initialize the log env in tests such that failures will show the log info
Unit tests. Mainly the console. It seems #168 does the initialization.