Monorepo: error handling tracking issue

[jochem-brouwer]

This issue summarizes issues/PRs raised in the past to improve monorepo error handling.

An old issue related to this is: #487

The core of the issue raised here is that errors themselves (new Error()) can only be distinguished by their error string. So, to compare errors (if a certain error is expected), can only be done by string. Therefore, changing the error string is a breaking issue. The idea here is to make a new class which extends Error, and add extra fields which can help for debug situations.

In EVM we already have EvmError:

export class EvmError {
  error: ERROR
  errorType: string

  constructor(error: ERROR) {
    this.error = error
    this.errorType = 'EvmError'
  }
}

The nice properties of this is that, if an error gets thrown, one can now:

catch(e: unknown) {
  if (e instanceof EvmError) {
    // error was thrown by evm, handle here
  } else {
    // another error (non-EVM) was thrown
  }
}

This old issue raises this idea as well: #1440 along with a discussion: #1439

There is also an old PR open which implements these ideas in a general was (in the util package) and errors in the block package: #1910

The general goal of this issue is:

• Ensure that monorepo-wide we align the way of error handling
• Errors are easily distinguishable by some kind of error code

This can be done per-package once we have created a way to base-handle these errors. (I will open a PR for this which also handles the errors that way in EVM)

This new EvmError class can be used to get rid of the any / unknown type in the catch blocks to help mature the error propagation in our libraries. See #3700

[gabrocheleau]

Linking this: #3712

[ScottyPoi]

Closed outdated #3700
That PR was working to eliminate instances of catch (err: any) or catch (e) { ...(e as any).message...}

Mostly this was found in tests doing:
catch (e: any) { assert.isTrue(e.message === 'expected error message' }

Since then we have mostly replaced that pattern with the vitest throws function.

So we can / should revisit the issue of eliminating (err: any) patterns, but the original PR was too outdated to be worth rebasing since most of those tests have been rewritten.

[jochem-brouwer]

Linking for completeness from #3880:

This shows how we could expand EVM errors where it could provide handy contextual data, such as revert bytes in case the EVM errors on a REVERT opcode:

ethereumjs-monorepo/packages/evm/src/errors.ts

Line 48 in 013c7ec

| { code: EVMErrorCode.REVERT; revertBytes: Uint8Array }