asyncawait icon indicating copy to clipboard operation
asyncawait copied to clipboard

Stack-trace is not usable

Open arogg opened this issue 9 years ago • 1 comments

In the documentation (https://github.com/yortus/asyncawait) it says that "will include a useable stack trace". But it does not for me. So I think I am doing it wrong..but I don't know what I'm doing wrong.

To demonstrate I will compare the stacktrace of a "vanilla" bluebird example with the corresponding stacktrace of the correspoding asyncawait code (asyncawait uses bluebird internally so I think it's fair).

First my bluebird code without asyncawait:

var funcB = (function() {
  return Promise.resolve().then(function() {
    throw new Error("some err");
  })
});

var funcA = function() {
  return funcB();
};

gulp.task("aa",function(cb) {
  funcA().then(function() {
    cb();
  });
});

The stacktrace yields the information "funcA -> funcB -> exception" at first glace. Perfect!

Error: Error: some err
    at processImmediate [as _immediateCallback] (timers.js:358:17)
From previous event:
    at funcB (C:\projects\JSBuildHelper\JSBuildHelper\tmp\tsreq\app\gulpfile.js:156:30)
    at funcA (C:\projects\JSBuildHelper\JSBuildHelper\tmp\tsreq\app\gulpfile.js:161:12)
    at Gulp.<anonymous> (C:\projects\JSBuildHelper\JSBuildHelper\tmp\tsreq\app\gulpfile.js:164:5)
    at module.exports (C:\projects\JSBuildHelper\JSBuildHelper\node_modules\gulp\node_modules\orchestrator\lib\runTask.js:34:7)
    at Gulp.Orchestrator._runTask (C:\projects\JSBuildHelper\JSBuildHelper\node_modules\gulp\node_modules\orchestrator\index.js:273:3)
    at Gulp.Orchestrator._runStep (C:\projects\JSBuildHelper\JSBuildHelper\node_modules\gulp\node_modules\orchestrator\index.js:214:10)
    at Gulp.Orchestrator.start (C:\projects\JSBuildHelper\JSBuildHelper\node_modules\gulp\node_modules\orchestrator\index.js:134:8)
    at C:\Users\alex\AppData\Roaming\npm\node_modules\gulp\bin\gulp.js:129:20
    at process._tickCallback (node.js:355:11)
    at Function.Module.runMain (module.js:503:11)
    at startup (node.js:129:16)
    at node.js:814:3

Now my asyncawait code:

var funcB = async(function() {
  throw new Error("some err");
});

var funcA = async(function () {
  await(funcB());
});

gulp.task("aa", function(cb) {
  funcA().then(function() {
    cb();
  });
});

In the corresponding stacktrace I only see the exception. No "funcA", no "funcB".

For this simple program it is sufficient. But I can't use it for other more complex stuff, considering how important stacktrances really are..

Possibly unhandled Error: Error: some err
    at catchBlock (C:\projects\JSBuildHelper\JSBuildHelper\node_modules\asyncawait\src\async\fiberManager.js:51:25)
    at runInFiber (C:\projects\JSBuildHelper\JSBuildHelper\node_modules\asyncawait\src\async\fiberManager.js:29:9)
From previous event:
    at new Promise (C:\projects\JSBuildHelper\JSBuildHelper\node_modules\asyncawait\node_modules\bluebird\js\main\promise.js:84:37)
    at defer (C:\projects\JSBuildHelper\JSBuildHelper\node_modules\asyncawait\src\async\defer.js:6:19)
    at nonIterable (C:\projects\JSBuildHelper\JSBuildHelper\node_modules\asyncawait\src\async\makeAsyncFunc.js:86:28)
    at f0 (C:\projects\JSBuildHelper\JSBuildHelper\node_modules\asyncawait\src\async\makeAsyncFunc.js:119:23)
    at Gulp.<anonymous> (C:\projects\JSBuildHelper\JSBuildHelper\tmp\tsreq\app\gulpfile.js:162:5)
    at module.exports (C:\projects\JSBuildHelper\JSBuildHelper\node_modules\gulp\node_modules\orchestrator\lib\runTask.js:34:7)
    at Gulp.Orchestrator._runTask (C:\projects\JSBuildHelper\JSBuildHelper\node_modules\gulp\node_modules\orchestrator\index.js:273:3)
    at Gulp.Orchestrator._runStep (C:\projects\JSBuildHelper\JSBuildHelper\node_modules\gulp\node_modules\orchestrator\index.js:214:10)
    at Gulp.Orchestrator.start (C:\projects\JSBuildHelper\JSBuildHelper\node_modules\gulp\node_modules\orchestrator\index.js:134:8)
    at C:\Users\alex\AppData\Roaming\npm\node_modules\gulp\bin\gulp.js:129:20
    at Function.Module.runMain (module.js:503:11)
    at startup (node.js:129:16)
    at node.js:814:3

Am I doing it wrong or is this really a limitition that I cannot remove?

arogg avatar Jul 18 '15 02:07 arogg

Hi @arogg,

You are doing it right. I've just tested your code and get the same result. So, the README is currently misleading, and I need to work on the code to improve stack traces.

Until then, it is just a limitation. I'd welcome a PR if you are inclined to make one, otherwise I'll look at improving this as soon as I have time.

yortus avatar Jul 21 '15 08:07 yortus