Closed Raynos closed 3 years ago
A meaningful stack trace is important.
However, node 15's default behavior of crashing on unhandled rejections violates language semantics - an unhandled rejection is not the same as an uncaught exception, and it's not supposed to fail the program overall, fast or otherwise.
It seems like the real issue is that https://github.com/substack/tape/blob/master/lib/test.js#L260 is creating a new Error, and thus a new stack trace, rather than preserving the original error instance. I think it should be doable to fix it so that either 1) when fail
is called with an error instance, the error instance is preserved, or 2) specifically in the case of a rejected promise returned to tape, we directly use _assert
or .emit
rather than passing it through .fail
.
Yeah I think calling self.ifError(err)
instead of self.fail(err)
should preserve the stack trace.
However we should probably double check the rejection is an Error
instance and call self.fail(reason)
with any non-Error reason.
When using
tape@5
instead oftape@4
a programmer error in my test program is captured bytape
and showing anot ok ${err.message}
The stack trace is the stack trace of tape itself handling
promise.catch()
( https://github.com/substack/tape/blob/master/lib/test.js#L113 ) instead of the stack trace for my code.I cannot tell which line of code in my test function has
.length of undefined
because tape is printing the wrong stack trace.Ideally tape would rethrow the
err
to the global process uncaught exception handler so that I can see the real stack trace and so that the tests can fail hard and fast immediately.