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

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

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

still relevant

abi.encodeError is not obviously the right way to solve these cases.
With #14913 we made a move towards treating custom errors as proper types - while we intentionally kept our options open between a single plain error type or a polymorphic class of error types, distinct for each custom error.

In either case, in the future we consider allowing to declare local variables of error type and being able to pass them along. As in:

error E(uint);
function f() {
  error e = E(42);
  require(false, e);
}

or in the latter version something more like

error E(uint);
function f() {
  error E(uint) e = E(42);
  require(false, e);
}

(which works much less gracefully until we switch to postfix types and is also less ideal until we have polymorphic functions)

In either case, the (only possible) semantics of these would be for the variable e to carry the ABI-encoded error data (so e.g. the first version would conceptually be type error = bytes memory;, if that was allowed).

And thus, the saner way to access the abi-encoding of an error would be by mere explicit conversion, as in bytes(e) (and thus also bytes(E(42))).

Now we can consider going the easier route of abi.encodeError as an immediate interim solution to be deprecated again later on - but we generally don't exactly like being put on the spot by opened PRs ;-).
I'm not yet entirely sure what to do about this particular case, but in general: could we try and discuss issues and their ramifications before jumping at implementations :-)? It's neither nice for us to have to reject work that's already put into a PR and it's also not nice for you to have wasted time, if it ends up being rejected, so it's always better to confirm with us first before starting to implement to avoid this kind of situation.