postgres icon indicating copy to clipboard operation
postgres copied to clipboard

Better error message for undefined values

Open mohe2015 opened this issue 3 years ago • 8 comments

Hello,

if possible I think it would be great if you could get better error messages if you accidentially pass undefined as parameter. Especially the query and the arguments would probably be helpful. Currently it seems like you get something like the following:

May 25 22:13:53 arch-luks2 node[11410]:       throw Errors.generic('UNDEFINED_VALUE', 'Undefined values are not allowed')
May 25 22:13:53 arch-luks2 node[11410]:                    ^
May 25 22:13:53 arch-luks2 node[11410]: Error: UNDEFINED_VALUE: Undefined values are not allowed
May 25 22:13:53 arch-luks2 node[11410]:     at handleValue (/opt/projektwahl-lit-production/node_modules/postgres/src/types.js:84:20)
May 25 22:13:53 arch-luks2 node[11410]:     at stringifyValue (/opt/projektwahl-lit-production/node_modules/postgres/src/types.js:114:5)
May 25 22:13:53 arch-luks2 node[11410]:     at stringify (/opt/projektwahl-lit-production/node_modules/postgres/src/types.js:101:16)
May 25 22:13:53 arch-luks2 node[11410]:     at fragment (/opt/projektwahl-lit-production/node_modules/postgres/src/types.js:120:10)
May 25 22:13:53 arch-luks2 node[11410]:     at stringifyValue (/opt/projektwahl-lit-production/node_modules/postgres/src/types.js:111:30)
May 25 22:13:53 arch-luks2 node[11410]:     at stringify (/opt/projektwahl-lit-production/node_modules/postgres/src/types.js:101:16)
May 25 22:13:53 arch-luks2 node[11410]:     at fragment (/opt/projektwahl-lit-production/node_modules/postgres/src/types.js:120:10)
May 25 22:13:53 arch-luks2 node[11410]:     at stringifyValue (/opt/projektwahl-lit-production/node_modules/postgres/src/types.js:111:30)
May 25 22:13:53 arch-luks2 node[11410]:     at stringify (/opt/projektwahl-lit-production/node_modules/postgres/src/types.js:101:16)
May 25 22:13:53 arch-luks2 node[11410]:     at fragment (/opt/projektwahl-lit-production/node_modules/postgres/src/types.js:120:10)
May 25 22:13:53 arch-luks2 node[11410]:   originCache.set(xs, new Error())
May 25 22:13:53 arch-luks2 node[11410]:                       ^
May 25 22:13:53 arch-luks2 node[11410]: Error
May 25 22:13:53 arch-luks2 node[11410]:     at cachedError (/opt/projektwahl-lit-production/node_modules/postgres/src/query.js:166:23)
May 25 22:13:53 arch-luks2 node[11410]:     at Query (/opt/projektwahl-lit-production/node_modules/postgres/src/query.js:36:24)
May 25 22:13:53 arch-luks2 node[11410]:     at sql3 (/opt/projektwahl-lit-production/node_modules/postgres/src/index.js:105:11)
May 25 22:13:53 arch-luks2 node[11410]:     at <anonymous> (/opt/projektwahl-lit-production/src/server/entities.ts:184:27)

mohe2015 avatar May 25 '22 20:05 mohe2015

I had the same issue, was throwing error and I had no idea what was throwing it, eventually tracked it down, but in all cases I want undefined to map to null so I just use the new transform: { undefined: null } option and I get no errors with a useful transform. I think make it the default behavior in future release

e3dio avatar May 25 '22 20:05 e3dio

I had the same issue, was throwing error and I had no idea what was throwing it, eventually tracked it down, but in all cases I want undefined to map to null so I just use the new transform: { undefined: null } option and I get no errors with a useful transform. I think make it the default behavior in future release

I don't think this should become the new default as it usually hides bugs.

mohe2015 avatar May 25 '22 21:05 mohe2015

Supposedly that's the current reason to not default transform to null, to me throwing a non-descript error and breaking query when I want undefined to map to null is worse, but it is debatable which way to default

e3dio avatar May 25 '22 21:05 e3dio

As I've stated earlier, the default behaviour is not going to be changed, no reason to discuss that further.

With that said, the error messages can indeed be improved. The very last line in the stack trace is where you hit gold, but perhaps we could include the string query context in the error message too.

let a
await sql`
  select * 
  from x 
  where y = ${ a }
`

would produce

 Error: UNDEFINED_VALUE: Undefined values are not allowed - found in:
  
  select * 
  from x 
  where y = $1
             ^

porsager avatar May 25 '22 21:05 porsager

My case was insert into table ${sql(data)} where undefined could have been any of 15 or 20 fields coming from different sources, a descriptive error would say which field was undefined if that is possible, if you are throwing errors for that etc

e3dio avatar May 25 '22 21:05 e3dio

Ah yes, that should be doable too!

porsager avatar May 25 '22 21:05 porsager

The very last line in the stack trace is where you hit gold ...

I'm using the partial query feature and therefore this was not thrown in the line it occurred. It may be useful to check this at creation of the partial query but that would be another fix as this still doesn't tell you which of the parameters of the template was undefined

mohe2015 avatar May 25 '22 21:05 mohe2015

@porsager: perhaps we could include the string query context in the error message too

That would be amazing!

I especially like the part of pointing to the exact line number + column of the code where the value is introduced, like the Next.js error overlay:

ReferenceError: Badgee is not defined

pages/index.tsx (650:37) @ eval

  648 | <div css={candidateBadgeStyles}>
  649 |   {!isEditing ? (
> 650 |     <Badgee
      |     ^
  651 |       data-cy="candidate-badge"
  652 |       color={
  653 |         (

Screen Shot 2022-08-02 at 18 22 05

karlhorky avatar Aug 09 '22 14:08 karlhorky