Skip to content

CLAUDE.md: error handling + test instructions updates #412

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.

Sign up for GitHub

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
malcolmgreaves wants to merge 1 commit into
base: main
Choose a base branch
from
+13 −4
Open

CLAUDE.md: error handling + test instructions updates #412

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 13 additions & 4 deletions .claude/CLAUDE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -51,6 +51,12 @@ cargo build --workspace # Debug build
```

### Testing
Many tests require the oxen server to be running. If it is not running on port 3000 and
a test fails because it cannot connect to oxen-server, then start it:
```bash
cargo run -p oxen-server start
```

Run specific tests:
```bash
cargo test test_function_name # Run specific matching tests
Expand Down Expand Up @@ -92,13 +98,16 @@ oxen push origin main # Push to remote
```

## Code Organization

- We define module exports in a `<module_name>.rs` file at the same level as the corresponding `module_name/` directory and *NOT* the older `mod.rs` pattern.

## Error Handling
- Use `OxenError` for all error types
- Functions should return `Result<T, OxenError>`
- Implement proper error propagation through the `?` operator
- Use the result type (`Result<T, Error>`) when an operation could fail.
- Never use `.unwrap()` or `.expect()` on a `Result` or on an `Option`.
+ Exception: In test-only code, it is ok to use use `.expect(<descrptive explanation of invariant that was violated>)` since we want to fail fast and have good stack traces for failing test cases.
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot Apr 3, 2026

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟡 Minor

Fix typo in test exception note.

The word "descrptive" is misspelled.

✏️ Proposed fix 
-  + Exception: In test-only code, it is ok to use use `.expect(<descrptive explanation of invariant that was violated>)` since we want to fail fast and have good stack traces for failing test cases.
+  + Exception: In test-only code, it is ok to use `.expect(<descriptive explanation of invariant that was violated>)` since we want to fail fast and have good stack traces for failing test cases.
🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In @.claude/CLAUDE.md at line 106, Fix the typo in the test-only code note:
change the misspelled word "descrptive" to "descriptive" inside the phrase
`.expect(<descrptive explanation of invariant that was violated>)` so it reads
`.expect(<descriptive explanation of invariant that was violated>)` in the test
exception note.

- Use as specific of an error type as possible for a function. Don't use a wider type unless it's necessary. When making modules and related pieces of code, try to use a locally-defined error enum for them if they all have similiar errors.
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot Apr 3, 2026

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟡 Minor

Fix typo in error type guidance.

"similiar" is misspelled.

✏️ Proposed fix 
-- Use as specific of an error type as possible for a function. Don't use a wider type unless it's necessary. When making modules and related pieces of code, try to use a locally-defined error enum for them if they all have similiar errors.
+- Use as specific of an error type as possible for a function. Don't use a wider type unless it's necessary. When making modules and related pieces of code, try to use a locally-defined error enum for them if they all have similar errors.
🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In @.claude/CLAUDE.md at line 107, In the sentence that reads "Use as specific
of an error type as possible for a function. Don't use a wider type unless it's
necessary. When making modules and related pieces of code, try to use a
locally-defined error enum for them if they all have similiar errors." fix the
typo by replacing the word "similiar" with the correct spelling "similar" so the
final sentence reads "...if they all have similar errors." and keep the
surrounding guidance unchanged.

- Make sure there's a `OxenError` variant for every error type. Be liberal in wrapping other modules error types, or other specific error types, in a new variant. Use a `Box<>` wrapper for it and have a `#[from]` to derive.
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot Apr 3, 2026

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟡 Minor

Fix typos in OxenError variant guidance.

Two issues on this line:

  • Article should be "an" before OxenError (vowel sound)
  • "similiar" is misspelled
✏️ Proposed fixes 
-- Make sure there's a `OxenError` variant for every error type. Be liberal in wrapping other modules error types, or other specific error types, in a new variant. Use a `Box<>` wrapper for it and have a `#[from]` to derive.
+- Make sure there's an `OxenError` variant for every error type. Be liberal in wrapping other modules error types, or other specific error types, in a new variant. Use a `Box<>` wrapper for it and have a `#[from]` to derive.
-- Make sure there's a `OxenError` variant for every error type. Be liberal in wrapping other modules error types, or other specific error types, in a new variant. Use a `Box<>` wrapper for it and have a `#[from]` to derive.
+- Make sure there's an `OxenError` variant for every error type. Be liberal in wrapping other modules error types, or other specific error types, in a new variant. Use a `Box<>` wrapper for it and have a `#[from]` to derive.

Actually, there's also "similiar" that needs fixing:

-- Use as specific of an error type as possible for a function. Don't use a wider type unless it's necessary. When making modules and related pieces of code, try to use a locally-defined error enum for them if they all have similiar errors.
+- Use as specific of an error type as possible for a function. Don't use a wider type unless it's necessary. When making modules and related pieces of code, try to use a locally-defined error enum for them if they all have similar errors.

Combined fix:

-- Make sure there's a `OxenError` variant for every error type. Be liberal in wrapping other modules error types, or other specific error types, in a new variant. Use a `Box<>` wrapper for it and have a `#[from]` to derive.
+- Make sure there's an `OxenError` variant for every error type. Be liberal in wrapping other modules error types, or other specific error types, in a new variant. Use a `Box<>` wrapper for it and have a `#[from]` to derive.
🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In @.claude/CLAUDE.md at line 108, Fix the typos in the guidance sentence so it
reads correctly: change "a `OxenError` variant" to "an `OxenError` variant" and
correct "similiar" to "similar" in the same line that references wrapping other
modules' error types and using `Box<>` with `#[from]`; keep the rest of the
guidance unchanged and ensure backticks around `OxenError`, `Box<>`, and
`#[from]` remain intact.

- `OxenError` is the top-level type for everything. If you need to unify different error types into one, use `OxenError`. These kinds of functions should return `Result<T, OxenError>`
- Implement proper error propagation through the `?` operator.

# Making Changes

Expand Down
Loading