feat: define common error types for each layer

[fohte]

Why

• Common error types are needed as the foundation for error propagation and diagnostics before implementing each layer
  • thiserror + anyhow preserves error chains while propagating errors across layer boundaries

What

• Define thiserror-derived error types for rules, config, and exec layers, with 54 tests verifying anyhow compatibility
  • Rules: PatternParseError, CommandParseError, RuleError, ExprError
  • Config: ConfigError, PresetError
  • Exec: ExecError, SandboxError, ExtensionError

---

[gemini-code-assist]

Summary of Changes

Hello @fohte, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request establishes a robust error handling foundation across the application's core layers: rules, configuration, and execution. It standardizes error reporting and propagation using the thiserror and anyhow crates, which will significantly improve diagnostic capabilities and maintainability as the project evolves.

Highlights

• Structured Error Types: Introduced common error types for the rules, config, and exec layers to provide a foundation for robust error propagation and diagnostics.
• Error Handling Libraries: Integrated thiserror for defining custom, strongly-typed error enums and anyhow for simplified, general-purpose error propagation and preserving error chains across layer boundaries.
• Specific Error Definitions: Defined PatternParseError, CommandParseError, RuleError, and ExprError for the rules layer; ConfigError and PresetError for the config layer; and ExecError, SandboxError, and ExtensionError for the execution layer.
• Comprehensive Testing: Added 54 unit tests across the new error modules to verify correct error display, source chain preservation, and anyhow compatibility for all newly defined error types.

Changelog

• Cargo.lock
  • Updated to include the anyhow dependency.
• Cargo.toml
  • Added anyhow = "1.0" to the project dependencies.
• src/config/error.rs
  • New file defining ConfigError and PresetError enums, covering I/O, preset fetching, validation, and circular references, complete with thiserror attributes and unit tests.
• src/config/mod.rs
  • New module file to expose the error types defined in error.rs.
• src/exec/error.rs
  • New file introducing ExecError, SandboxError, and ExtensionError enums, addressing command execution, sandboxing, and external extension issues, with thiserror integration and tests.
• src/exec/mod.rs
  • New module file to expose the error types defined in error.rs.
• src/lib.rs
  • Modified to declare config, exec, and rules as public modules.
• src/rules/error.rs
  • New file containing PatternParseError, CommandParseError, RuleError, and ExprError enums, designed for parsing, command interpretation, rule evaluation, and expression handling, fully integrated with thiserror and tested.
• src/rules/mod.rs
  • New module file to expose the error types defined in error.rs.

Activity

• The pull request introduces a comprehensive suite of 54 unit tests across the newly defined error modules (src/config/error.rs, src/exec/error.rs, src/rules/error.rs) to validate the correct behavior, display formatting, and anyhow compatibility of all error types.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 2 additional findings.

[gemini-code-assist]

Code Review

This pull request does an excellent job of establishing a solid foundation for error handling across different layers of the application. The use of thiserror and anyhow is idiomatic and well-executed. The new error types are well-defined, and the test coverage is comprehensive, including checks for error chaining with anyhow. I have one suggestion in src/rules/error.rs to further improve the error wrapping consistency.

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 5 additional findings in Devin Review.