来自 catch 的请求承诺堆栈跟踪
request-promise stack trace from catch
我目前正在使用 'request-promise' 库进行来自 node-js 的 API 调用,并努力从 'catch' 函数获得正确的调用堆栈。玩了一会儿之后,我注意到一个我无法解释的有趣行为。假设我有代码:
.catch(err => {
console.log(err.stack);
console.log('!!!');
console.log(new Error().stack);
});
在控制台中,我实际上看到 'err' 和 'new Error()' 两个完全不同的堆栈跟踪:
StatusCodeError: 404 - [object Object]
at new StatusCodeError (C:\MyProject\request-promise\lib\errors.js:26:15)
at Request.RP$callback [as _callback] (C:\MyProject\request-promise\lib\rp.js:68:32)
at Request.self.callback (C:\MyProject\request-promise\node_modules\request\request.js:187:22)
at Request.emit (events.js:110:17)
at Request.<anonymous> (C:\MyProject\request-promise\node_modules\request\request.js:1048:10)
at Request.emit (events.js:107:17)
at IncomingMessage.<anonymous> (C:\MyProject\request-promise\node_modules\request\request.js:969:12)
at IncomingMessage.emit (events.js:129:20)
at _stream_readable.js:908:16
at process._tickCallback (node.js:355:11)
!!!
Error
at C:/MyProject/src/server/controllers/bookingController.js:81:19
at tryCatcher (C:\MyProject\request-promise\node_modules\bluebird\js\main\util.js:26:23)
at Promise._settlePromiseFromHandler (C:\MyProject\request-promise\node_modules\bluebird\js\main\promise.js:510:31)
at Promise._settlePromiseAt (C:\MyProject\request-promise\node_modules\bluebird\js\main\promise.js:584:18)
at Promise._settlePromises (C:\MyProject\request-promise\node_modules\bluebird\js\main\promise.js:700:14)
at Async._drainQueue (C:\MyProject\request-promise\node_modules\bluebird\js\main\async.js:123:16)
at Async._drainQueues (C:\MyProject\request-promise\node_modules\bluebird\js\main\async.js:133:10)
at Immediate.Async.drainQueues [as _onImmediate] (C:\MyProject\request-promise\node_modules\bluebird\js\main\async.js:15:14)
at processImmediate [as _immediateCallback] (timers.js:367:17)
如您所见,'new Error()' 提供了有关调用堆栈的更多有用信息,因为它具有
'C:/MyProject/src/server/controllers/bookingController.js'
我想那是因为 'err' 异常是用前一个 tick 创建的,因此它的堆栈跟踪与我的 'bookingController.js' 没有任何关系。
此外,我看到 'request-promise' 在内部使用 'bluebird',所以从技术上讲我可以使用 Promise.longStackTraces()。
最后,我的问题是:除了使用 'new Error().stack' 技巧之外,是否有更聪明的方法来获得正确的堆栈跟踪,因为 Promise.longStackTraces() 对于生产来说性能太重?
好吧,nodejs 提供了一种更漂亮的方式来捕获 nodeJS 上的实际堆栈,这适合我的需要:
let capturedStack = {};
Error.captureStackTrace(capturedStack, writeStack);
console.log(capturedStack.stack);
我目前正在使用 'request-promise' 库进行来自 node-js 的 API 调用,并努力从 'catch' 函数获得正确的调用堆栈。玩了一会儿之后,我注意到一个我无法解释的有趣行为。假设我有代码:
.catch(err => {
console.log(err.stack);
console.log('!!!');
console.log(new Error().stack);
});
在控制台中,我实际上看到 'err' 和 'new Error()' 两个完全不同的堆栈跟踪:
StatusCodeError: 404 - [object Object]
at new StatusCodeError (C:\MyProject\request-promise\lib\errors.js:26:15)
at Request.RP$callback [as _callback] (C:\MyProject\request-promise\lib\rp.js:68:32)
at Request.self.callback (C:\MyProject\request-promise\node_modules\request\request.js:187:22)
at Request.emit (events.js:110:17)
at Request.<anonymous> (C:\MyProject\request-promise\node_modules\request\request.js:1048:10)
at Request.emit (events.js:107:17)
at IncomingMessage.<anonymous> (C:\MyProject\request-promise\node_modules\request\request.js:969:12)
at IncomingMessage.emit (events.js:129:20)
at _stream_readable.js:908:16
at process._tickCallback (node.js:355:11)
!!!
Error
at C:/MyProject/src/server/controllers/bookingController.js:81:19
at tryCatcher (C:\MyProject\request-promise\node_modules\bluebird\js\main\util.js:26:23)
at Promise._settlePromiseFromHandler (C:\MyProject\request-promise\node_modules\bluebird\js\main\promise.js:510:31)
at Promise._settlePromiseAt (C:\MyProject\request-promise\node_modules\bluebird\js\main\promise.js:584:18)
at Promise._settlePromises (C:\MyProject\request-promise\node_modules\bluebird\js\main\promise.js:700:14)
at Async._drainQueue (C:\MyProject\request-promise\node_modules\bluebird\js\main\async.js:123:16)
at Async._drainQueues (C:\MyProject\request-promise\node_modules\bluebird\js\main\async.js:133:10)
at Immediate.Async.drainQueues [as _onImmediate] (C:\MyProject\request-promise\node_modules\bluebird\js\main\async.js:15:14)
at processImmediate [as _immediateCallback] (timers.js:367:17)
如您所见,'new Error()' 提供了有关调用堆栈的更多有用信息,因为它具有
'C:/MyProject/src/server/controllers/bookingController.js'
我想那是因为 'err' 异常是用前一个 tick 创建的,因此它的堆栈跟踪与我的 'bookingController.js' 没有任何关系。
此外,我看到 'request-promise' 在内部使用 'bluebird',所以从技术上讲我可以使用 Promise.longStackTraces()。
最后,我的问题是:除了使用 'new Error().stack' 技巧之外,是否有更聪明的方法来获得正确的堆栈跟踪,因为 Promise.longStackTraces() 对于生产来说性能太重?
好吧,nodejs 提供了一种更漂亮的方式来捕获 nodeJS 上的实际堆栈,这适合我的需要:
let capturedStack = {};
Error.captureStackTrace(capturedStack, writeStack);
console.log(capturedStack.stack);