Automatic checking of information in error logs/error return types?
from taladar@sh.itjust.works to rust@programming.dev on 11 Jan 2024 14:48
https://sh.itjust.works/post/12568660

After adding some lines today to log some information I had missed that was vital for debugging I was wondering if there were any automated tools like linters or similar static analysis tools that help you identity the information to log and or return in error cases.

I am specifically talking about the information that should be identifiable automatically because it contributes to the control flow arriving in the current scope such as values of variables in the condition for the scope or parameters of functions that calculate those values (e.g. the file name in a permission error, the value of a variable that failed an if let or let else pattern match,…

#rust

BB_C@programming.dev on 12 Jan 2024 01:36 collapse

If you’re not familiar with the tracing crate, give the instrument page a read. You may find the #[instrument(err)] part particularly useful.

As for the errors themselves, if you’re using thiserror (you should be), then the variants in your error enum would/should contain the relevant context data. And the chain of errors would be tracked via source/#[source] fields, as explained in the crate docs. You can see such chains if you use anyhow in your application code.

taladar@sh.itjust.works on 12 Jan 2024 07:00 collapse

I didn’t know about #[instrument(err)] but in general I am well aware of the ways to log and return errors,

I am more concerned with ways to prevent myself from accidentally forgetting to log some relevant information until the first time that error is logged somewhere where I need to debug the actual problem and then having to essentially create a new version just to add that logging (if I am lucky enough for the error to be reproducible at all).