Better understandable errors

[benllshua]

Let's take this simple example:

just put this anywhere in your codebase

z.string().parse(5)

this is the error you will get (as you should):

The default error needs to include the location of the error, line of code, and variable name... currently, I think it's really hard to locate errors without writing costume errors for everything (optional: if you don't want it to get to users we can throw an error with one message and return a simpler user-friendly error )

[JacobWeisenburger]

This seems a bit out of scope for zod

[JacobWeisenburger]

Perhaps safeParse would help you. Then you could handle the error however you see fit, rather than throwing and potentially crashing your program.

[benllshua]

Well I thought more will agree with me but perhaps you are right...

I think my case is good when using zod for situations like env variables and such, I can always parse a costume message manually

[JacobWeisenburger]

Can I move this to a discussion? Or would you like it to stay as a feature request?

[benllshua]

Please leave it as a feature request, if other developers doesn't agree with me, close it or move it to discussion s...

[colinhacks]

@benllshua The line & column number should appear a few lines above the part that you screenshotted. I agree it would be nice to clean up the stack trace a little if it's possible to do in a runtime-agnostic way.

[m10rten]

This seems like a user-skill-issue.

You can add error messages to almost any Zod object, string, array, number, validation rule, etc.
Then just safeParse and use the result.data and result.error with correct error message.

[colinhacks]

I disagree, this is a very real issue:

The default error needs to include the location of the error, line of code, and variable name... currently, I think it's really hard to locate errors without writing costume errors for everything

It's definitely problematic that all ZodErrors appear to originate inside Zod's source code instead of at the point where .parse() was called.

[reidark]

Hi,

There is something being made to address this? I think it's a pain point because we don't know where the errors were thrown.
I'm saying this because I have a wrapper to catch all my errors (neverthrow style) and log them. The problem with Zod parse is that I'm not getting the exact location, so I have to create a wrapper function just to get that.

I know that we can work with safeParse and do a lot with stuff just with the values, but I don't think this resolves the issue inside Zod.

Right now I'm doing something like this to work (example generated with AI):

function parseWithCallsite<T>(schema: { parse: (v: unknown) => T }, value: unknown): T {
  const callsiteError = new Error("parse callsite");
  Error.captureStackTrace?.(callsiteError, parseWithCallsite);

  try {
    return schema.parse(value);
  } catch (err) {
    if (err instanceof Error) {
      // Keep the original validation error stack, but add the callsite stack.
      (err as any).callsiteStack = callsiteError.stack;
    }
    throw err;
  }
}

Get the location from Zod validation would be much better and would help a lot.

What do you guys think?