Caught errors are not distinguishable from uncaught errors

[lewischa]

In v3.20.x errors handled via the catch operator are logged along with errors that actually cause the parsing to fail. This makes it difficult to differentiate "fatal", uncaught errors from non-fatal, caught/handled errors. This isn't a huge deal in smaller schemas, but becomes very tedious with larger ones.

Is there a way to suppress caught errors from parse and safeParse, or perhaps mark them as caught?

Example

See the interactive example on Stackblitz, but here's the code for a minimal reproduction:

const schema = z.object({
  stringProp: z.string(),
  numberPropWithCatch: z.number().catch(0),
});

schema.parse({
  // This value is of incorrect type and causes the parsing to fail
  stringProp: {},
  // This value is of incorrect type as well, but DOESN'T
  // cause parsing to fail as it's caught in the schema.
  // However, the error is reported in the overall list
  // of parsing errors.
  numberPropWithCatch: '',
});

Running this code results in an error as expected, but notice how both the fatal and caught errors are displayed:

[JacobWeisenburger]

This seems like a bug to me. I don't think numberPropWithCatch should show up in the errors.

const schema = z.object( {
    stringProp: z.string(),
    numberPropWithCatch: z.number().catch( 0 ),
} )

const result = schema.safeParse( {
    stringProp: {},
    numberPropWithCatch: '',
} )

!result.success && console.log( result.error.flatten() )
// {
//     formErrors: [],
//     fieldErrors: {
//       stringProp: [ "Expected string, received object" ],
//       numberPropWithCatch: [ "Expected number, received string" ]
//     }
// }

[colinhacks]

Agreed. Good catch!

[maxArturo]

@lewischa @JacobWeisenburger took a crack at this on #1926. Let me know what you think!

[lewischa]

Thank you all! Is there a "dev" or "beta" release that includes that fix, or would you recommend forking/cloning?