Hi there, I think require, revert and assert provide great flexibility in logic flow controls. One of the quirks about Solidity is an economically-efficient programmer has to constantly think about gas usage. If you search for advice on gas saving advice on Google, you’ll get articles about an advice on reducing the length of error messages in the above three functions. That said, I’m just wondering if Solidity can have some built-in error messages that are cost-effective. I’m trying to do that on my own and have got a list of scenarios that could be standardized. Maybe OZ is more suitable for designing this, I’m not sure. It may or may not be built in Solidity, but I think at least a list of such designs can be achieved and adopted on a community-wide scope.
ERROR1: NOT THE TOKEN OWNER
ERROR2: ALREADY THE OWNER
ERROR3: OWNER ONLY
ERROR4: TOKEN DOES NOT EXIST
ERROR5: INSUFFICIENT AMOUNT
ERROR6: INVALID AMOUNT
ERROR7: BOARD ADDRESS and CALLING ADDRESS DO NOT MATCH
Sure, it does help. Since it’s on a blockchain, I could not help but thinking about gas usage. Is a custom error costing more gas or less than a plain error message indicating where and what an error is.
It will usually cost less gas than error strings, provided it doesn’t have any arguments. You can look at the “errors in depth” section of the above link to get a comparison.
Custom errors are like events, being able to incorporate parameter names and values. Sometimes, a plain and simple ERR-1 or ERR-12 is needed with enough information to know what is going on while having gas costs under control. That feature-request in the link does show a similar interest.
Sure, I will give it a shot. But again, since this is a new feature, for any unexperienced programmer, it would be great if a list of errors like below is maintained somewhere in the forum or github:
The problem is that these are highly specific to concepts that are not language primitives but are instead built on top of them: tokens, ownable contracts, etc. In my opinion it’s stuff that belongs a layer above the compiler. Standard library could be a place for it in some languages, but the one we will likely provide in the near future (see Standard library brainstorming · Issue #10282 · ethereum/solidity · GitHub) is shaping up to be much more low-level. In that light OZ would probably be a better place for such a list.
However, having seen lots of projects in various languages, I don’t think that anything but a very generic list of error codes will hold up in practice. Errors are usually very application-specific and often it’s hard to keep a consistent list of codes even within a single project, let alone across multiple projects.
You only pay the additional gas cost for error message strings on deployment or when the error is actually hit. The cost per byte for deployment is pretty low and the runtime cost of copying a larger string around in memory is also pretty low. In bath cases when you pay the cast, it is low and you .robably don’t care that much about savings.
If you are looking to reduce runtime gas costs, there are way better things to target than reducing error length.
