[DRAFT] Custom Errors for ENSIP-10

[adraffy]

• proposal (unfinished)
• took comment from slack and created ENSIP per Nick's suggestion
• defined an ordering (contrary to the original design)

---

Original design:

example of (1): error Unreachable(bytes name)
example of (2): error UnknownResolverProfile(bytes4 selector)

when name doesn't exist, reverts Unreachable
when name exists and f() isn't implemented, reverts UnknownResolverProfile
when name exists, and f() is implemented, but f(name) is doesn't exist/is null, then returns null

you could then probe if a name exists by calling resolve(name, 0x00000000) to see if it reverts UnknownResolverProfile or Unreachable

by "exists", i mean "answerable by the resolver", however resolvers with actual availability could certainly be more precise

[adraffy]

Contrary to the original design, I made it clear in the spec that UnsupportedResolverProfile happens before UnreachableName. After looking at many resolvers, it seems most developers branch on calldata they understand, before interacting with name or making an offchain request.

Explicit ordering is not required but it seems like a nice property to have as it enables the ERC-165-like behavior.

However, this ordering causes my hacky idea above about resolve(name, 0x00000000) to not work as stated.

It seems reasonable to assume that almost all resolvers implement addr(), so receiving UnreachableName when querying addr() is effectively isExists(name). There may be text()-only resolvers, but if addr() reverts UnsupportedResolverProfile, it could try text() as a fallback. Alternatively, this could be multicalled as [addr(), text()] and return false if either call reverts UnreachableName.

Possibly, the proposal should state that UnsupportedResolverProfile can be probed with w/CCIP-Read disabled.

It's unclear if we should have an explicit resolver profile for existence checking. Since zero resolvers implement this today, probably not. But if so, this would be the right time to define one.