docs: show string status names in lifecycle and error handling

[braden-w]

This PR extends string status name examples to two essential documentation files: life-cycle.md and error-handling.md. When developers read these core concepts, they'll now see inline comments showing that status() accepts both numeric codes (like 401) and string names (like "Unauthorized"), making it easier to discover this convenient feature.

This change is part of a broader effort across PRs #739 and #741-#745 to improve string status name visibility throughout the documentation. By showing both options in context, we help users find the API style that works best for their code without having to dig through reference docs.

Summary by CodeRabbit

• Documentation
  • Enhanced error handling documentation with new examples.
  • Clarified support for both numeric and string status code formats.
  • Added references to additional status code resources.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Two documentation files are updated to demonstrate alternative syntax for HTTP status codes in error handling examples. Changes show using string literals (e.g., status('Unauthorized'), status("I'm a teapot")) alongside numeric codes, with added reference links to Status and Headers documentation.

Changes

Cohort / File(s)	Summary
Documentation: Status Code Syntax Examples docs/essential/life-cycle.md, docs/patterns/error-handling.md	Updated and expanded examples showing alternative status code syntax using string literals instead of numeric codes; added reference links to Status and Headers documentation

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

• Both changes are straightforward documentation updates with no logic or functional implications

Poem

🐰 A rabbit's tale of status strings,
Where 401 becomes Unauthorized wings,
And 418 brews teapots galore,
Documentation blooms, forevermore!

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and specifically describes the main change: adding examples of string status names in the life-cycle and error-handling documentation files.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5e5da8b and ca95968.

📒 Files selected for processing (2)

• docs/essential/life-cycle.md (2 hunks)
• docs/patterns/error-handling.md (1 hunks)

🔇 Additional comments (4)

docs/essential/life-cycle.md (2)

505-505: Verify that status('Unauthorized') is a valid API pattern.

Elysia documentation indicates you can set a status code using the common name of the status code instead of using a number, but all discovered examples show numeric codes in the status() helper (e.g., status(418, "message")). By contrast, string status names are used with set.status directly (e.g., set.status = "I'm a teapot").

Confirm whether status('Unauthorized') with a string-only parameter is valid, or whether the example should use set.status = 'Unauthorized' or a numeric code like status(401).

---

529-531: Consistency check: Verify the guard example's status API usage.

The same concern applies here: common name status codes are documented, but the pattern status('Unauthorized') needs verification against the actual API. Ensure this example is consistent with the pattern used in line 505, and that both are valid.

docs/patterns/error-handling.md (2)

311-311: Verify the string-only status() parameter pattern.

This addition mentions that status(418) can also use status("I'm a teapot") instead. However, based on Elysia's documentation patterns, the status() helper typically uses numeric codes with an optional message parameter (e.g., status(418, "message")), while string status names are directly assigned to set.status (e.g., set.status = "I'm a teapot").

Confirm whether status("I'm a teapot") as a string-only parameter is a supported API pattern, or if the documentation should clarify that string names are used with set.status instead.

---

311-311: Ensure the referenced documentation link is accessible.

Verify that the link to /tutorial/getting-started/status-and-headers is accurate and publicly accessible. This will help readers find additional context about string vs. numeric status codes.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[braden-w]

Superseded by #747 (conversions) and #748 (contextual notes)