[feature-request] Error code system, based on Yulish style error"..."

[SilentCicero]

Abstract

Revert error messages take up a huge amount of byte space, especially for larger builds.

Motivation

You making us crazy.

Suggestion, have a simple error code system, which delivers a map of error codes at compile time. This way error code messages are not baked into the contract itself, which is wasteful.

Suggestion:

// my sol file .sol

require(someAssertion, error"my-error-code-message");

// compiled build .json

{
   "abi": [],
   "bytecode": "0x",
   "errors": {
       "0": "my-error-code-message",
   },
}

Specification

Error codes are registered in order, are unique, and properly map to the output in the build. We do this in Yul+ and it has been a huge savings for larger deployments.

Notation is similar to hex"", i.e. error"".

Backwards Compatibility

Not sure on this one.

[chriseth]

I cannot dig up the issue number now, but we are planning to add custom errors to 0.8 in the way of

error MyErorrKind(/*potential parameters */)

why can then be used like

throw MyErrorKind(/*potential arguments */);
require(x, MyErrorKind())

and

try ... { ... } catch MyError(/* variables */) { ... }

The implementation would use function signatures in the same way as the ABI, so if you don't have arguments, it needs 4 bytes and a memory write.

Would that work here?

[cameel]

I think it was #7877.

[SilentCicero]

@chriseth so the emit Error might be okay, but my system as you can see is very simple. Very basic. Just mainly to avoid the headache of string bloat with error messages.

I feel mine would be easier to implement, but sure, the above might do it. How are errors interpreted outside in testing environments?

The reason why I like my direction is it's clear, the strings are registered in the compiled output, and can be hooked into testing environments.

I do this with Yul+ and it works great.

[chriseth]

Here is a new writeup that also contains some more context: https://hackmd.io/b0vr4MFrSkCLlBEacnds0Q

The advantage of typed errors is that you can properly catch them in catch statements and you can also have longer string explanations in NatSpec documentation that is exported via the ABI.

[cameel]

Is this issue still relevant now that we have custom errors implemented?

[axic]

I think the proposal is different to the error system, as the current one still uses more bytes than suggested.

Probably it is up to @SilentCicero to decide if this is pursued further or not.

[github-actions]

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

[github-actions]

Hi everyone! This issue has been automatically closed due to inactivity.
If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen.
However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.