"Wouldn’t it be great if you could see errors in place instead of mysterious NULLs?"
It's not a good ad when the error message is inadequate even in the supplied example and you need to hack around it.
It's not a good ad when the error message is inadequate even in the supplied example and you need to hack around it.
error({
stage: "transform",
err: "input error",
value: {
stage: "normalize",
err: "input error",
value: {
stage: "metrics",
err: "divide by zero",
value: {
sum: 123.5,
n: 0
}
}
}
})
... and you can quickly deduce that your "metrics" stage is dividing by "n" even if n is 0 and you can fix up your logic as well as fix the errors in place after fixing the bug in the ingest pipeline.There's no need to repeat the infamous MSSQL "String or binary data would be truncated" message saga here - there's no reason you can't give much more verbose errors by default.