You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Restore the ability to return error object from maps
In views we drop any rows which throw errors. Sometimes users may want to
either record which docs throw errors and build an error "key space" by doing
`emit(['error', doc._id], e)` or something similar.
This used to work in Spidermonkey 1.8.5, where `Error` objects were json
stringified as objects with `message` and `name` fields. Newer Javascript
engines like Spidermonkey 91 and QuickJS, however, stringify `Error` objects as
`{}`. That's expected according to the Javascript standard, but is not as nice
for users who want to debug their map functions.
Users can of course still do `e.toString()` to stringify the error before
emitting it, or emit the `.message` or `.name` separately, but since simply
emitting or logging the error used to work, we can try bringing it back and let
users to the same with the newer JS engines.
Implementation-wise, the initial attempt of using `value instanceof Error`
unexpecteldy failed, and Jan had solved the mystery - since `emit()` functions
run in a sandbox, the `Error` object in the sandbox wasn't the same as the
`Error` object in our emit wrapper code, so that always returned `false`. To
solve that issue we opted to use some duck-typing, and see if the value is an
object, is not null (`in` operator doesn't work on nulls), and then has the
expected `Error` properties.
The same thing applies to the `log()` function so we can try to do the check
there.
Thanks to Will Holley for noticing this issue and suggesting the solution, and
to Jan Lehnardt for solving the `instanceof` sandbox mystery.
0 commit comments