Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve error message for INVALID OPERATION opcode #8141

Merged
merged 5 commits into from
Jan 21, 2025

Conversation

matkt
Copy link
Contributor

@matkt matkt commented Jan 20, 2025

PR description

This PR updates the behavior of the invalid operation opcode to return an error that includes the problematic opcode in the message, replacing the previous generic message.

Fixed Issue(s)

Thanks for sending a pull request! Have you done the following?

  • Checked out our contribution guidelines?
  • Considered documentation and added the doc-change-required label to this PR if updates are required.
  • Considered the changelog and included an update if required.
  • For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

  • unit tests: ./gradlew build
  • acceptance tests: ./gradlew acceptanceTest
  • integration tests: ./gradlew integrationTest
  • reference tests: ./gradlew ethereum:referenceTests:referenceTests

@matkt matkt changed the title invalid operation return error with the invalid opcode Improve error message for INVALID_OPERATION Jan 20, 2025
@matkt matkt changed the title Improve error message for INVALID_OPERATION Improve error message for INVALID OPERATION opcode Jan 20, 2025
@matkt matkt marked this pull request as ready for review January 20, 2025 09:03
@matkt
Copy link
Contributor Author

matkt commented Jan 20, 2025

this is the evm specific PR @shemnon for #8129

Signed-off-by: Karim Taam <[email protected]>
public String toString() {
return name();
}
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of having the factory method here, move this ExceptionalHaltReason definition to its class, e.g.:

  static ExceptionalHaltReason newInvalidOperation(final long opcode) {
    return new ExceptionalHaltReason() {
      @Override
      public String name() {
        return INVALID_OPERATION.name();
      }

      @Override
      public String getDescription() {
        return "invalid opcode: 0x%02x".formatted(opcode);
      }

      @Override
      public String toString() {
        return name();
      }
    };
  }

And then call it like so here:

new OperationResult(0L, ExceptionalHaltReason.newInvalidOperation(getOpcode()));

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure it's better but I don't have a strong opinion about that so I will do the change

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think keeping all ExceptionHaltReason definitions in one place is best

@matkt matkt enabled auto-merge (squash) January 21, 2025 08:54
@matkt matkt merged commit 6d05f83 into hyperledger:main Jan 21, 2025
43 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants