Incorrect Error Handling Would Make Debugging Difficult #71
Labels
bug
Something isn't working
downgraded by judge
Judge downgraded the risk level of this issue
grade-b
insufficient quality report
This report is not of sufficient quality
Q-13
QA (Quality Assurance)
Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax
Lines of code
https://github.com/code-423n4/2024-02-hydradx//blob/main/HydraDX-node/pallets/omnipool/src/traits.rs#L171
Vulnerability details
Proof of Concept
The code uses
map_err(|_| ())?
in several places to handle errors. This approach discards the original error and replaces it with (). While this is a simple way to handle errors, it can make debugging difficult if an error occurs, as there will be no information about what the original error was.For Example
Impact
In this line, if get_price returns an error, map_err converts it into (), and then the ? operator immediately returns this from the current function. This means that if get_price fails, we'll know that an error occurred, but we won't know why. and it would make it difficult to track errors while debugging
Tools Used
Manual
Recommended Mitigation Steps
A better approach would be to define a custom error type that can hold different kinds of errors. This way, we can convert the original error into our custom error type, preserving the original error information. Here's an example:
In this version, if get_price fails, its error is wrapped in the MyError::OracleError variant, and then this is returned from the current function. This preserves the original error information, making it easier to debug what went wrong.
Assessed type
Error
The text was updated successfully, but these errors were encountered: