Better error message for undefined values
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)
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 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
undefinedto map tonullso I just use the newtransform: { 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.
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
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
^
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
Ah yes, that should be doable too!
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
@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 | (
