Awesome Reviewers

Handle errors in a predictable, maintainable way by (1) ensuring all failure-path variables are defined, (2) handling exceptions at one layer (no redundant try/catch), (3) validating external data at boundaries with Zod, and (4) using stable structured error fields instead of brittle string message matching.

Apply this standard:

• Compile/runtime safety: don’t reference variables that are only defined in other branches. Prefer computing shared values once (e.g., const effectiveX = ...) before divergent logic.
• Single responsibility for exception handling: if a helper already catches/logs, don’t re-catch the same promise at the call site unless you’re adding materially different handling.
• Validate untrusted inputs: when transforming API responses (e.g., social media payloads), validate with Zod (including transforms) before use.
• Stable error contracts: when processing backend responses, branch on errorCode/numeric data/typed status fields rather than matching exact message strings.

Example pattern (stable errors + boundary validation):

import { z } from "zod";

const ResponseSchema = z.object({
  status: z.enum(["ok", "error"]),
  errorCode: z.number().optional(),
  message: z.string().optional(),
  chunkedInput: z.string(),
});

const parsed = ResponseSchema.parse(await vectorSaveResponse.json());
if (parsed.status !== "ok") {
  // Don’t match exact message strings; use a stable code/field.
  if (parsed.errorCode === 123) {
    // handle specific condition
  } else {
    throw new Error(`Memory save failed${parsed.message ? `: ${parsed.message}` : ""}`);
  }
}

This reduces runtime failures, prevents inconsistent handling across layers, and makes error-handling logic resilient to message wording changes.

This site is open source. Improve this page.