fix: code typo on error handling tutorial

[abiriadev]

the code is calling status() function from the context, but the handler parameter missed it.

```typescript
import { Elysia } from 'elysia'

new Elysia()
-	.onError(({ error, code }) => {
+	.onError(({ code, status }) => { // get `status`
		if(code === "NOT_FOUND")
			return 'uhe~ are you lost?'

		return status(418, "My bad! But I\'m cute so you'll forgive me, right?") // where the error happens
	})
	.get('/', () => 'ok')
	.listen(3000)

Summary by CodeRabbit

• Refactor
  • Updated error handler callback parameter structure. The error handler now receives code and status instead of error and code, providing direct access to response status for improved error response customization.

[coderabbitai]

Walkthrough

The onError handler parameter destructuring in the docs was changed from ({ error, code }) to ({ code, status }), removing the error property and introducing status.

Changes

Cohort / File(s)	Change Summary
Error Handler Signature Update docs/tutorial/patterns/error-handling/index.md	Changed onError callback parameters from { error, code } to { code, status } in the example; removed error and added status

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Poem

🐇 I hopped through docs with a tiny cheer,
Swapped an error for status—now clear.
Lines trimmed lightly, a tidy new view,
A rabbit's small change, simple and true. 🥕

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 "fix: code typo on error handling tutorial" accurately describes the changeset. The pull request modifies the error-handling tutorial by correcting the parameter destructuring in the onError callback from ({ error, code }) to ({ code, status }), which fixes a code example where the destructured parameters didn't match what was actually used in the handler (the status function). The title is specific, concise, and clearly conveys that this is a code fix to the error-handling documentation example.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

🧪 Generate unit tests (beta)

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

---

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.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

docs/tutorial/patterns/error-handling/index.md (1)

43-48: Clarify parameter availability in onError handler documentation.

The first example (line 43) destructures { code, status }, while a later example (line 72) destructures { error, code, status }. This inconsistency may confuse readers about which parameters are available or required.

Add a brief explanation clarifying that:

• All three parameters (error, code, status) are available in the onError handler
• The first example omits error because it's not needed for that use case
• The second example includes error because it accesses the error object

This would help readers understand that parameter destructuring is flexible based on their needs.

Also applies to: 72-79

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 21bbd06 and f49a738.

📒 Files selected for processing (1)

• docs/tutorial/patterns/error-handling/index.md (1 hunks)

🧰 Additional context used

🪛 markdownlint-cli2 (0.18.1)

docs/tutorial/patterns/error-handling/index.md

43-43: Hard tabs
Column: 1

(MD010, no-hard-tabs)

[coderabbitai]

Actionable comments posted: 0

♻️ Duplicate comments (1)

docs/tutorial/patterns/error-handling/index.md (1)

43-43: Hard tabs persist: use spaces for markdown consistency.

A previous review flagged hard tabs on this line (MD010 violation), but they appear to remain. Replace the leading hard tab(s) with spaces to align with markdown formatting standards and the file's indentation style.

-	.onError(({ code, status }) => {
+    .onError(({ code, status }) => {

🧹 Nitpick comments (2)

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

35-37: Documentation should clarify available context properties.

The context description lists error and code, but omits status — which is demonstrated in the first code example on line 47 where status(...) is called. The first example also destructures only { code, status }, not error, which may confuse readers about what's available and required.

Update the context description to include status and clarify that error is optional (used only when handling specific custom errors):

It accept **context** similar to handler but include an additional:
-- error - a thrown error
+- error - a thrown error (available for custom error handling)
- <DocLink href="/essential/life-cycle#error-code">code</DocLink> - error code
+- <DocLink href="/essential/handler#status">status</DocLink> - status function to override the error response

---

43-48: Inconsistent destructuring patterns between examples.

The first example (line 43) destructures only { code, status }, while the second example (line 72) destructures { error, code, status }. This inconsistency may suggest that error is required in some cases but not others, which needs clarification. Consider adding a brief comment explaining when error is needed (e.g., only for custom error handling with type narrowing).

Also applies to: 72-79

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f49a738 and 380d711.

📒 Files selected for processing (1)

• docs/tutorial/patterns/error-handling/index.md (1 hunks)