Problem: Some functions return Result<()> and print errors to the console directly. This makes it hard for calling functions to handle different error types or change the logging behavior.
Suggestion: Propagate errors using Result<()> and handle them at a higher level (e.g., in the execute method of a command). This makes the lower-level functions more reusable and testable.
Minimal change example (conceptual):
// In a function within src/github/api.rs
pub async fn some_api_call() -> Result<()> {
let result = // ... api call
if result.is_err() {
println!("API call failed: {}", result.err().unwrap());
return Ok(()); // Error is swallowed
}
// ...
Ok(())
}
Instead of this pattern in a low-level function:
// In a function within src/github/api.rs
pub async fn some_api_call() -> Result<ApiResponse> {
let response = // ... api call
response.error_for_status().map_err(anyhow::Error::from)
// ... return Ok(response)
}
The calling function in pr.rs would then handle the Result. This is a slightly larger change but significantly improves maintainability.
Problem: Some functions return Result<()> and print errors to the console directly. This makes it hard for calling functions to handle different error types or change the logging behavior.
Suggestion: Propagate errors using
Result<()>and handle them at a higher level (e.g., in theexecutemethod of a command). This makes the lower-level functions more reusable and testable.Minimal change example (conceptual):
Instead of this pattern in a low-level function:
The calling function in
pr.rswould then handle theResult. This is a slightly larger change but significantly improves maintainability.