fix: JSON-RPC server returns spec-compliant errors

[alexghr]

Fix #2510

Checklist:

Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge.

• If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag.
• I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code.
• Every change is related to the PR description.
• I have linked this pull request to relevant issues (if any exist).

[benesjan]

Looks good 👍

[benesjan]

Do you think we would want to use here implementation-defined server-errors?

I think it would be a nice thing to have.

If you agree please create the issue and add a comment next to the code with TODO #issue_number and we'll tackle that in a separate PR.

[alexghr]

I think that's a good idea, but won't be easy to implement because errors can be thrown by different components in the system 🤔. I think we should still do it, but in the meantime maybe a different error code would be more appropriate here? I see Ethereum uses -32000 which is the first of the 'server reserved range' as a default error code.

[benesjan]

but won't be easy to implement because errors can be thrown by different components in the system

I think we could just extend an error like this:

class AztecError extends Error {

  constructor(public readonly code: number, message: string) {
    super(message);
  }
}

and then iterate through all the occurrences of throw new Error in our codebase and use it there.

[alexghr]

Yep! I think though that it would make sense to have an enum for error codes so that RPC clients don't end up having to handle the same error code for two different types of errors, e.g.:

enum ErrorCode {
  InvalidAztecAddress = 10000
}

// in some API
throw new AztecError(ErrorCode.InvalidAztecAddress, "invalid address")