Skip to content

core/vm: Enhance EVM error handling with structured error types #31950

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jtn-dev
Copy link

@jtn-dev jtn-dev commented Jun 2, 2025

Summary

This PR significantly improves the EVM error handling system by introducing structured error types that provide rich contextual information for debugging.

Changes

  • New Error Types: GasError, StackError, MemoryError with detailed context
  • Enhanced Messages: Transform "out of gas" → "gas error in SSTORE: required 20000, available 5000"
  • Full Testing: Comprehensive unit and integration tests
  • Documentation: Complete usage guide and examples
  • Backward Compatible: Zero breaking changes

Benefits

  • Improved debugging experience for developers
  • Type-safe error handling
  • Better tooling integration possibilities
  • Enhanced monitoring capabilities

Testing

  • ✅ All existing tests pass
  • ✅ New unit tests for error types
  • ✅ Integration tests with real EVM scenarios
  • ✅ Performance benchmarks show minimal overhead

Files Modified

  • core/vm/errors.go - New structured error types
  • core/vm/interpreter.go - Stack error integration
  • core/vm/instructions.go - Memory error context
  • core/vm/errors_test.go - Unit tests
  • core/vm/errors_integration_test.go - Integration tests
  • core/vm/README_ERRORS.md - Documentation

… GasError, StackError, MemoryError with rich context - Transform generic errors into detailed messages - Comprehensive testing and documentation included - Maintains full backward compatibility
@MariusVanDerWijden
Copy link
Member

Could you expand a bit on why you think these additional error types are useful?
Especially why do you want to replace the underflow and overflow errors?

@jtn-dev
Copy link
Author

jtn-dev commented Jun 5, 2025

Could you expand a bit on why you think these additional error types are useful?

Instead of vague errors, you get specific details:
Old: "stack underflow (1 <=> 2)"
New: "stack error in ADD: required 2 items, available 1"
Code can inspect specific error details programmatically.

Especially why do you want to replace the underflow and overflow errors?

Context matters: Knowing which operation caused the stack error is crucial for debugging
Consistency: All errors follow the same structured pattern
Extensibility: Easy to add more debugging info later
The key improvement: instead of just knowing "something went wrong with the stack," you know "ADD operation failed because it needed 2 stack items but only had 1."

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