errore

errore

Go-style error handling for TypeScript. Functions return errors instead of throwing them — but instead of Go's two-value tuple (val, err), you return a single Error | T union. Instead of checking err != nil, you check instanceof Error. TypeScript narrows the type automatically. No wrapper types, no Result monads, just unions and instanceof.

const user = await getUser(id)
if (user instanceof Error) return user // early return, like Go
console.log(user.name) // TypeScript knows: User

Rules

Each rule is one line; the details live once in the pattern sections below.

1. Always import * as errore from 'errore' — namespace import, never destructure

2. Never throw for expected failures — return errors as values

3. Never return unknown | Error — the union collapses to unknown, breaks narrowing. Common trap: res.json() returns unknown, so return await res.json() makes the return type MyError | unknown → unknown. Fix: cast with as → return (await res.json()) as User

4. Convert exceptions to values only at boundaries — .catch() for async, errore.try for sync (see Boundaries). Never try-catch for control flow

5. Always wrap boundary catches in a tagged domain error with cause — .catch((e) => new MyError({ cause: e })). Never .catch((e) => e as Error), never omit cause (it preserves the chain for debugging and abort detection)

6. Use createTaggedError for domain errors (see Defining Errors); use cause to wrap errors

7. Use | null for optional values, not | undefined — three-way narrowing: instanceof Error, === null, then value

8. Use const + expressions, never let + try-catch (see Expressions over Statements)

9. Handle errors inside if branches with early exits, keep the happy path at root indentation (see Flat Control Flow)

10. Always include Error handler in matchError — required fallback for plain Error instances

11. Always prefer errore.try over errore.tryFn — same function, errore.try is the canonical name

12. Abort: custom abort errors MUST extend errore.AbortError, detect with errore.isAbortError (never error.name === 'AbortError'), and check isAbortError(result) as its own early return before instanceof Error (see Abort & Cancellation)

13. Don't reassign after error early returns — TypeScript narrows the original variable; a const narrowed = result alias is redundant

14. Write instanceof Error early returns on one line — if (result instanceof Error) return result. Use a { block only when the branch has more than one statement

15. Always log errors that are not propagated — when an error branch doesn't return or throw (loops with continue, fallback branches, fire-and-forget calls), add a console.warn/console.error so the failure leaves a trace. Propagated errors don't need logging — the caller handles them:

    const emailResult = await sendEmail(user.email).catch(
      (e) => new EmailError({ email: user.email, cause: e }),
    )
    if (emailResult instanceof Error) {
      console.warn('Failed to send email:', emailResult.message)
    }
    

16. Always hint a solution in user-facing error messages — include a login URL, CLI command, or missing flag so agents and users can self-correct instead of guessing. Applies to HTTP responses and CLI output; internal errors (DB failures, parse errors) can stay technical:

    class UnauthorizedError extends errore.createTaggedError({
      name: 'UnauthorizedError',
      message: 'Not logged in. Sign in at $loginUrl or run: $loginCommand',
    }) {}
    

TypeScript Rules

• Object args over positional — ({id, retries}) not (id, retries) for functions with 2+ params

• Expressions over statements — use IIFEs, ternaries, .map/.filter instead of let + mutation

• Early returns — check and return at top, don't nest. Combine conditions: if (a && b) not if (a) { if (b) }

• No any — search for proper types, use as unknown as T only as last resort

• cause not template strings — new Error("msg", { cause: e }) not new Error(`msg ${e}`)

• No uninitialized let — use IIFE with returns instead of let x; if (...) { x = ... }

• Type empty arrays — const items: string[] = [] not const items = []

• Module imports for node builtins — import fs from 'node:fs' then fs.readFileSync(...), not named imports

• Let TypeScript infer return types — inferred types are always correct. Annotate only when it genuinely improves readability (complex unions, public API boundaries) or when inference produces a wider type than intended

• .filter(isTruthy) not .filter(Boolean) — Boolean doesn't narrow types, so (T | null)[] stays (T | null)[] after filtering. Use a type guard:

  function isTruthy<T>(value: T): value is NonNullable<T> {
    return Boolean(value)
  }
  const items = results.filter(isTruthy)
  

Flat Control Flow

Keep block nesting minimal. Every level of indentation is cognitive load. The ideal function reads top to bottom at root level — checks and early returns, no else, no nested if, no try-catch.

Core pattern — call → check error → exit if error → continue at root. This is the single most important structural rule. Identical structure to Go's if err != nil { return err } blocks — speed bumps the reader skips over while scanning the left edge:

const user = await getUser(id)
if (user instanceof Error) return user

const posts = await getPosts(user.id)
if (posts instanceof Error) return posts

return render(user, posts)

No else — early return eliminates it: if (x) return 'A'; return 'B'

No else if chains — sequence of early-return if blocks:

function getStatus(code: number): string {
  if (code === 200) return 'ok'
  if (code === 404) return 'not found'
  if (code >= 500) return 'server error'
  return 'unknown'
}

Flatten nested if — invert conditions and return early. if (A) { if (B) { ... } } becomes if (!A) return; if (!B) return; .... Take the outermost if condition, negate it, return the failure case, then continue at root level. Repeat for each nested if. The happy path falls through to the end.

Avoid try-catch for control flow — try-catch is the worst offender for nesting. It forces a two-branch structure (try + catch) and hides which line threw. Convert exceptions to values at boundaries:

async function loadConfig(): Promise<Config> {
  const raw = await fs
    .readFile('config.json', 'utf-8')
    .catch((e) => new ConfigError({ reason: 'Read failed', cause: e }))
  if (raw instanceof Error) return { port: 3000 }

  const parsed = errore.try(
    () => JSON.parse(raw) as Config,
    (e) => new ConfigError({ reason: 'Invalid JSON', cause: e }),
  )
  if (parsed instanceof Error) return { port: 3000 }

  if (!parsed.port) return { port: 3000 }

  return parsed
}

Errors in branches, happy path at root — always handle errors inside if blocks, never success logic. Error handling goes in branches with early exits. Putting success logic inside if blocks inverts the flow and buries the happy path. If you see !(x instanceof Error) in a condition, you've inverted the pattern — flip it.

Same in loops — error in if + continue, happy path flat:

for (const id of ids) {
  const item = await fetchItem(id)
  if (item instanceof Error) {
    console.warn('Skipping', id, item.message)
    continue
  }
  await processItem(item)
  results.push(item)
}

Patterns

Expressions over Statements

Always prefer const with an expression over let assigned later. This eliminates mutable state and makes control flow explicit. Escalate by complexity:

Simple: ternary

const user = fetchResult instanceof Error ? fallbackUser : fetchResult

Medium: IIFE with early returns — when a ternary gets too nested or involves multiple checks, use an IIFE. It scopes all intermediate variables and uses early returns for clarity:

const config: Config = (() => {
  const envResult = loadFromEnv()
  if (!(envResult instanceof Error)) return envResult
  const fileResult = loadFromFile()
  if (!(fileResult instanceof Error)) return fileResult
  return defaultConfig
})()

Every let x; if (...) { x = ... } can be rewritten as const x = ternary or const x: T = (() => { ... })(). The IIFE pattern is idiomatic in errore code — it keeps error handling flat with early returns while producing a single immutable binding.

Defining Errors

import * as errore from 'errore'

class NotFoundError extends errore.createTaggedError({
  name: 'NotFoundError',
  message: 'User $id not found in $database',
}) {}

createTaggedError gives you _tag, typed $variable properties, cause, findCause, toJSON, fingerprinting, and a static .is() type guard — all for free. Omit message to let the caller provide it at construction time: new MyError({ message: 'details' }). The fingerprint stays stable. Reserved variable names that cannot be used in templates: $_tag, $name, $stack, $cause.

Instance properties:

err._tag // 'NotFoundError'
err.id // 'abc' (from $id)
err.database // 'users' (from $database)
err.message // 'User abc not found in users'
err.messageTemplate // 'User $id not found in $database'
err.fingerprint // ['NotFoundError', 'User $id not found in $database']
err.cause // original error if wrapped
err.toJSON() // structured JSON with all properties
err.findCause(DbError) // walks .cause chain, returns typed match or undefined
NotFoundError.is(val) // static type guard

Returning Errors

async function getUser(id: string) {
  const user = await db.findUser(id)
  if (!user) return new NotFoundError({ id, database: 'users' })
  return user
}

Return the error, don't throw it. The return type tells callers exactly what can go wrong.

Boundaries (.catch for async, errore.try for sync)

.catch() and errore.try should only appear at the lowest level of your call stack — right at the boundary with code you don't control (third-party libraries, JSON.parse, fetch, file I/O, etc.). Your own functions return errors as values, so they never need .catch() or try.

For async boundaries: .catch((e) => new MyError({ cause: e })) directly on the promise. For sync boundaries: errore.try(() => ..., (e) => ...). The .catch() callback receives any (Promise rejections are untyped), but wrapping in a typed error gives the union a concrete type — no as assertions needed. TypeScript infers the union automatically:

async function getUser(id: string) {
  const res = await fetch(`/users/${id}`).catch(
    (e) => new NetworkError({ url: `/users/${id}`, cause: e }),
  )
  if (res instanceof Error) return res

  if (!res.ok) return new NetworkError({ url: `/users/${id}`, reason: `HTTP ${res.status}` })

  const data = await (res.json() as Promise<UserPayload>).catch(
    (e) => new NetworkError({ url: `/users/${id}`, cause: e }),
  )
  if (data instanceof Error) return data

  if (!data.active) return new InactiveUserError({ id })
  return { ...data, displayName: `${data.first} ${data.last}` }
}

Think of .catch() and errore.try as the adapter between the throwing world (external code) and the errore world (errors as values). Once you've converted exceptions to values at the boundary, everything above is plain instanceof checks.

Optional Values (| null)

async function findUser(email: string): Promise<DbError | User | null> {
  const result = await db
    .query(email)
    .catch((e) => new DbError({ message: 'Query failed', cause: e }))
  if (result instanceof Error) return result
  return result ?? null
}

// Caller: three-way narrowing
const user = await findUser('[email protected]')
if (user instanceof Error) return user
if (user === null) return
console.log(user.name) // User

Error | T | null gives you three distinct states without nesting Result and Option types.

Parallel Operations

const [userResult, postsResult, statsResult] = await Promise.all([
  getUser(id),
  getPosts(id),
  getStats(id),
])

if (userResult instanceof Error) return userResult
if (postsResult instanceof Error) return postsResult
if (statsResult instanceof Error) return statsResult

return { user: userResult, posts: postsResult, stats: statsResult }

Each result is checked individually. You know exactly which operation failed.

Exhaustive Matching (matchError)

const response = errore.matchError(error, {
  NotFoundError: (e) => ({
    status: 404,
    body: { error: `${e.table} ${e.id} not found` },
  }),
  DbError: (e) => ({ status: 500, body: { error: 'Database error' } }),
  Error: (e) => ({ status: 500, body: { error: 'Unexpected error' } }),
})
return res.status(response.status).json(response.body)

matchError routes by _tag and requires an Error fallback for plain Error instances. Use matchErrorPartial when you only need to handle some cases.

Resource Cleanup (defer) — Replacing try/finally with using

try/finally has a structural problem: every resource adds a nesting level. Two resources = two levels of indentation, and cleanup is split across finally blocks far from where the resource was acquired. await using + DisposableStack keeps the function flat — one cleanup.defer() per resource, same indentation whether you have one resource or ten. Cleanup runs automatically in reverse (LIFO) order on every exit path — normal return, early error return, or exception.

tsconfig requirement: add "ESNext.Disposable" to lib:

{
  "compilerOptions": {
    "lib": ["ES2022", "ESNext.Disposable"],
  },
}

async function importData(url: string, dbUrl: string): Promise<ImportError | { rows: number }> {
  await using cleanup = new errore.AsyncDisposableStack()

  const db = await connectDb(dbUrl).catch((e) => new ImportError({ reason: 'db connect', cause: e }))
  if (db instanceof Error) return db
  cleanup.defer(() => db.close())

  const tmpFile = await createTempFile()
  cleanup.defer(() => tmpFile.delete())

  const response = await fetch(url).catch((e) => new ImportError({ reason: 'fetch', cause: e }))
  if (response instanceof Error) return response

  await tmpFile.write(await response.text())
  await db.import(tmpFile.path)
  return { rows: await db.count() }
  // cleanup: tmpFile.delete() → db.close()
}

Adding a resource is one line (cleanup.defer()), not another nesting level. The errore polyfill handles the runtime; the tsconfig lib entry handles the types.

Fallback Values

const result = errore.try(() =>
  JSON.parse(fs.readFileSync('config.json', 'utf-8')),
)
const config = result instanceof Error ? { port: 3000, debug: false } : result

Ternary on instanceof Error replaces let + try-catch. Single expression, no mutation, no intermediate state.

Walking the Cause Chain (findCause)

const dbErr = error.findCause(DbError)
if (dbErr) {
  console.log(dbErr.host) // type-safe access
}

// Or standalone function for any Error
const dbErr = errore.findCause(error, DbError)

findCause checks the error itself first, then walks .cause recursively. Returns the matched error with full type inference, or undefined. Safe against circular references.

Custom Base Classes

class AppError extends Error {
  statusCode = 500
  toResponse() {
    return { error: this.message, code: this.statusCode }
  }
}

class NotFoundError extends errore.createTaggedError({
  name: 'NotFoundError',
  message: 'Resource $id not found',
  extends: AppError,
}) {
  statusCode = 404
}

const err = new NotFoundError({ id: '123' })
err.toResponse() // { error: 'Resource 123 not found', code: 404 }
err instanceof AppError // true
err instanceof Error // true

Use extends to inherit shared functionality (HTTP status codes, logging methods, response formatting) across all your domain errors.

Boundary with Legacy Code

async function legacyHandler(id: string) {
  const user = await getUser(id)
  if (user instanceof Error) throw new Error('Failed to get user', { cause: user })
  return user
}

At boundaries where legacy code expects exceptions, check instanceof Error and throw with cause. This preserves the error chain and keeps the pattern consistent.

Converting { data, error } Returns

Some SDKs (Supabase, Stripe, etc.) return { data, error } instead of throwing. Destructure inline, check error first with a truthy check (not instanceof — most SDKs return plain objects), wrap in a tagged error, then continue with data:

const { data, error } = await supabase.from('users').select('*').eq('id', id)
if (error) return new SupabaseError({ cause: error })
if (data === null) return new NotFoundError({ id })
// data is narrowed here

Wrapping in a domain error is better than returning the SDK's error directly — gives you _tag, typed properties, and the cause chain.

Partition: Splitting Successes and Failures

const allResults = await Promise.all(ids.map((id) => fetchItem(id)))
const [items, errors] = errore.partition(allResults)

errors.forEach((e) => console.warn('Failed:', e.message))
// items contains only successful results, fully typed

partition splits an array of (Error | T)[] into [T[], Error[]]. No manual accumulation.

Abort & Cancellation

controller.abort(reason) throws reason as-is — whatever you pass is what .catch() receives. This means you MUST pass a typed error extending errore.AbortError, never a plain Error or string — otherwise isAbortError can't detect it.

Always use errore.isAbortError(error) to detect abort errors — never check error.name === 'AbortError' manually, because tagged abort errors have their tag as .name. isAbortError walks the entire .cause chain, so it works even when the abort error is wrapped by .catch().

Keep abort checks flat: isAbortError(result) first as its own early return, then result instanceof Error as a separate early return. Never nest one inside the other.

import * as errore from 'errore'

class TimeoutError extends errore.createTaggedError({
  name: 'TimeoutError',
  message: 'Request timed out for $operation',
  extends: errore.AbortError,
}) {}

const controller = new AbortController()
const timer = setTimeout(
  () => controller.abort(new TimeoutError({ operation: 'fetch' })),
  5000,
)

const res = await fetch(url, { signal: controller.signal }).catch(
  (e) => new NetworkError({ url, cause: e }),
)
clearTimeout(timer)

if (errore.isAbortError(res)) return res
if (res instanceof Error) return res

isAbortError detects three kinds of abort: (1) native DOMException from bare controller.abort(), (2) direct errore.AbortError instances, (3) tagged errors that extend errore.AbortError — even when wrapped in another error's .cause chain.

Early Return on Abort (signal.aborted checks)

Check signal.aborted before side effects or async operations — same early-return pattern as errors but for cancellation. Without these, cancelled work keeps running.

for (const item of items) {
  if (signal.aborted) return                    // before work
  const data = await fetchData(item.id, { signal })
    .catch((e) => new FetchError({ id: item.id, cause: e }))
  if (errore.isAbortError(data)) return         // after async
  if (data instanceof Error) { console.warn(data.message); continue }
  if (signal.aborted) return                    // before write
  await db.save(data)
}

Place signal.aborted checks before expensive operations (network, db writes, file I/O). Check isAbortError after async calls that received the signal. Both keep the function responsive to cancellation.

Linting

If the project uses lintcn, read docs/lintcn.md for the no-unhandled-error rule that catches discarded Error | T return values.

Pitfalls

CustomError | Error is ambiguous when CustomError extends Error

// BAD: both sides of the union are Error instances
type Result = MyCustomError | Error
// instanceof Error matches BOTH — can't distinguish success from failure
// Success types must never extend Error