Schema's `ParseError` does not extend `Error`

[sofiaritz]

Hi!

If I understood correctly from reading the library's code and trying to debug some issues, Schema's ParseError does not seem to extend Error, which breaks some error handling systems (in my case, Hono's error handling) due to ParseError instanceof Error being false. AFAIK in the 0.x version it does extend Error.

Is this the case? If so, is this expected behavior? Thank you for your work! :)

EDIT: For completeness, my application is running in Deno and the dependency is specified as npm:typebox@^1.3.9

[sinclairzx81]

@sofiaritz Hello!

If I understood correctly from reading the library's code and trying to debug some issues, Schema's ParseError does not seem to extend Error, which breaks some error handling systems (in my case, Hono's error handling) due to ParseError instanceof Error being false. AFAIK in the 0.x version it does extend Error. Is this the case? If so, is this expected behavior?

Yeah, this was intentional, but I wasn't aware that it was causing problems for Hono. Hmmm.

Schema.ParseError

There are a couple of reasons why Schema.ParseError does not extend Error. The first is purely an optimization. globalThis.Error causes the runtime to collect the callstack on throw, which is very slow. The second is that a serialized callstack reveals information about the software that threw the error. So the reasons were 50% performance and 50% security-related.

On performance though, you can test the difference locally below:

function benchmark(name: string, func: Function) {
  console.time(name)
  for(let i = 0; i < 1_000_000; i++) func()
  console.timeEnd(name)
}
// ------------------------------------------------
// Error | With Callstack
// ------------------------------------------------
benchmark('Error', () => {
  try { throw new globalThis.Error('error') } catch { }
})
// ------------------------------------------------
// FastError | Without Callstack
// ------------------------------------------------
class FastError { constructor(message: string) {} }
benchmark('FastError', () => {
  try { throw new FastError('error') } catch { }
})
// ------------------------------------------------
// Result
// ------------------------------------------------
// Error:     2002ms
// FastError: 158ms

HonoParse | HonoError

Would something like the following work? This code would wrap both Schema.Parse and Schema.ParseError with Hono-specific implementations. This would be in line with the general TB design moving forward (where applications centralize and map errors in accordance with surrounding infrastructure, Hono in this case)

TypeScript Link Here

import Schema from 'typebox/schema'
// ------------------------------------------------------------------
// HonoError
// ------------------------------------------------------------------
export class HonoError extends Error {
  constructor(message: string) { super(message) }
}
// ------------------------------------------------------------------
// HonoParse
// ------------------------------------------------------------------
function HonoParse<const Schema extends object>(schema: Schema, value: unknown) {
  try {
    // todo: add additional "forward" processing here if required.
    return Schema.Parse(schema, value)
  } catch (error) {
    // catch fast - re-throw Hono application error.
    if(error instanceof Schema.ParseError) {
      // map expected data structures here
      throw new HonoError(JSON.stringify(error.errors, null, 2))
    } else {
      throw new HonoError('unknown error') 
    }
  }
}
const result = HonoParse({ 
  type: 'object',
  required: ['x', 'y', 'z'],
  properties: {
    x: { type: 'number' },
    y: { type: 'number' },
    z: { type: 'number' },
  }
}, { x: 'not a number' })

---

Let me know if the HonoParse and HonoError wrappers work. Also, thanks for reporting. I wasn't aware that Hono required an Error exception. There's some existing Hono middleware using the Value.* infrastructure currently (which does extend Error); knowing that Hono requires errors to extend Error will be helpful when planning out 2.x.

Let me know how you go
S