contracts
contracts copied to clipboard
drips-network
Switch to custom errors
As @byterose wrote in #45:
Custom errors decrease both deploy and runtime gas costs. Additionally all expected errors are listed in the abi file which can be used to improve the UX of contract interactions.
If this issue is still of interest, I would be open to push a pr.
Custom errors are similar to NatSpec comments in the sense that they are not required but can improve the developer and user experience.
The user experience is the thing I'm most afraid about. AFAIU custom errors are lightweight integer IDs with optional details payloads. To know what an ID means a tool needs to look up the contract ABI, e.g. on Etherscan. How well supported is this flow across the ecosystem? E.g. if an error is thrown and your wallet software can only tell you that "an error 123456 occured", that's bad user experience. String errors are widely supported and provide everything needed to form a proper error message. They're also very easy to debug.
I understand that the potential low ecosystem support is a concern at the moment but I am also convinced that this will be the standard for smart contract interactions in the near future. In addition to that I want to point out that these custom error messages can be used for crafting front-end notifications and would therefore support front-end developers. It is a nice addition if both deploy and runtime gas costs decrease.
On the other hand, as you said, "errors are widely supported and provide everything needed to form a proper error message".
The gas cost argument IMO isn't a very important one. For runtime, errors are very rarely thrown in the actually mined transactions. For deployment yes, it'll be a bit cheaper, but we're talking about 24 requires, let's say 32 characters each, which adds up to ~750 bytes. Custom errors IDs are 4 bytes each, so the savings would be in the ballpark of ~650 bytes.
I think that the biggest advantage of custom errors is what can be done with them in the UI with proper error handling, error message translations and precise details about what's wrong.
I support that change, I'm only not sure if the ecosystem is ready for it and if we'll shoot ourselves in the foot by chasing the shiny new conventions.
Precise evaluation! Since the ecosystem moves fast and these contracts will probably be used for a significant timeframe, I suggest we wait until foundry comes up with a stable release and then come back to this issue. Otherwise it will be hard to write tests for custom errors.