Skip to content
d3 Wiki
04.06

Error handling and logging

Failures are visible, actionable, and never silent.

Updated
Oct 3, 2026
On this page

Purpose

Failures are visible, actionable, and never silent.

The standard

  • Fail fast at boundaries (validate input); handle expected errors explicitly; let unexpected ones surface with context.

  • Users see a plain-language message and a reference id; developers see the stack trace in logs. Never show raw errors to users.

  • Web: error.tsx boundaries per route group; server actions return { ok, data | error } rather than throwing across the client boundary.

  • Log levels: error (needs action), warn (degraded), info (business events), debug (local only). Structured JSON in production.

  • Never log secrets, tokens, or full request bodies with personal data.

  • Rhino/Revit: catch at the command boundary, show a dialog with the message and a "copy details" button, write full detail to %APPDATA%/[TEAM]/logs/.

  • Production errors go to [TEAM: Sentry / Vercel logs]; owner reviews weekly (06.06).

Owner: Matt · Last reviewed: 2026-09