Allow errors.py as the error handler module's name (error.py also works)#47
Conversation
📝 WalkthroughWalkthroughSupport for root-module names "error.py" and "errors.py" was added across docs, types, and loader (preferring Changes
Sequence Diagram(s)(Skipped — changes are localized and do not introduce a multi-component sequential flow requiring visualization.) Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
Pre-merge checks❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro 📒 Files selected for processing (2)
🧰 Additional context used🪛 LanguageToolREADME.md[style] ~29-~29: Consider using a more formal and expressive alternative to ‘awesome’. (AWESOME) docs/index.md[style] ~20-~20: Consider using a more formal and expressive alternative to ‘awesome’. (AWESOME) 🔇 Additional comments (4)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
docs/guides/error-handling.md (1)
11-11: Document the precedence when both files exist.The documentation mentions that both
error.pyanderrors.pyare supported but doesn't clarify what happens when both files are present in the same directory. Based on the AI summary,errors.pytakes precedence, but this should be explicitly documented to avoid user confusion.Suggested documentation update
Consider adding a note like:
-With all that said, let's set up error handling by adding the `error.py` or `errors.py` file to the root of our project (next to `main.py`). +With all that said, let's set up error handling by adding the `error.py` or `errors.py` file to the root of our project (next to `main.py`). If both files exist, `errors.py` takes precedence.docs/application-components.md (1)
113-113: Document the file precedence behavior.Similar to the guide, this documentation should clarify what happens when both
error.pyanderrors.pyexist. This is particularly important in this comprehensive documentation section.Suggested clarification
Consider adding a note about precedence:
-Error handlers are defined in the `error.py` or `errors.py` module of the root package as a `handlers` variable, which can be a mapping from exception types or HTTP status codes to standard FastAPI exception handler functions, or a callable that expects a `fasthx.htmy.HTMY` positional argument and returns such a mapping. The latter option is useful if you want to do custom HTML rendering in an error handler. +Error handlers are defined in the `error.py` or `errors.py` module of the root package as a `handlers` variable, which can be a mapping from exception types or HTTP status codes to standard FastAPI exception handler functions, or a callable that expects a `fasthx.htmy.HTMY` positional argument and returns such a mapping. If both files exist, `errors.py` takes precedence. The latter option is useful if you want to do custom HTML rendering in an error handler.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
docs/application-components.mddocs/guides/error-handling.mdholm/_model.pyholm/app.pyholm/logging.pyholm/modules/_error.pyholm/typing.pytest_app/errors.py
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-12-22T23:11:22.422Z
Learnt from: volfpeter
Repo: volfpeter/holm PR: 42
File: examples/forms/page.py:15-15
Timestamp: 2025-12-22T23:11:22.422Z
Learning: In htmy v0.10.0 and later, do not use html tag objects (e.g., html.div, html.form, html.head) as type hints or return types. Replace these with htmy's ComponentType or Component for type annotations in Python code (e.g., def render(...) -> Component or def handler(...) -> ComponentType). Apply this consistently across Python files where htmy HTML tag objects are used in type hints.
Applied to files:
holm/logging.pyholm/modules/_error.pyholm/_model.pyholm/app.pyholm/typing.py
🧬 Code graph analysis (2)
holm/modules/_error.py (1)
holm/_model.py (2)
PackageInfo(103-190)import_module(124-159)
holm/app.py (2)
holm/modules/_error.py (2)
load_error_handler_owner(34-50)register_error_handlers(53-68)holm/modules/_layout.py (1)
htmy(78-79)
🔇 Additional comments (8)
holm/logging.py (1)
1-3: LGTM!The centralized logger setup follows Python logging best practices and provides a consistent logging interface for the entire package.
holm/typing.py (1)
6-6: LGTM!The type expansion correctly adds
"errors"as a valid root-only module name while maintaining backward compatibility with existing"error"usage. The change automatically propagates throughModuleNameand themodule_namesset.holm/_model.py (2)
10-10: LGTM!The refactor to use the centralized logger from
holm.loggingimproves consistency across the package while maintaining identical logging behavior.
152-153: LGTM!The logger usage remains functionally identical after the centralization refactor.
holm/modules/_error.py (2)
8-10: LGTM! Import additions support the new function.The added imports (
PackageInfoandlogger) are necessary for the newload_error_handler_ownerfunction and are correctly sourced from internal modules.
34-50: LGTM! Clean implementation that achieves the PR objective.The function correctly attempts to load both
errors.pyanderror.py, prioritizingerrors.pywhen both exist. The warning message is helpful for users who might have accidentally created both modules. The implementation handles all edge cases appropriately (neither exists, one exists, both exist).holm/app.py (2)
22-22: LGTM! Import addition is correct.The addition of
load_error_handler_ownerto the imports is necessary for the updated error handler loading approach on line 55.
54-55: LGTM! Clean refactoring that centralizes error handler loading.The updated approach correctly delegates error handler module discovery to
load_error_handler_owner, which now supports botherror.pyanderrors.pynaming conventions. The refactoring improves code organization by centralizing this logic in the_errormodule.
Closes #46
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.