eriwen
commented
9 years ago In order to leverage source maps and other static analysis, ajax requests for map files and sources must be made.
Version 0.x of stacktrace.js users synchronous ajax for this purpose. That feature causes slowness and is being deprecated by browsers.
If you only want to parse a stacktrace in a cross browser way, you can use stacktracejs/error-stack-parser. Please let us know if that is insufficient for your needs.
On Sun, Mar 8, 2015 at 7:21 AM, Septagram notifications@github.com wrote:
I've been using version 0.6.0 for a while in one of the projects, with great success. However, just now I noticed that there's a newer version that relies on promises a lot, and that the top of the master branch only allows returning the stack trace as a promise. I love promises myself and use them heavily. Promises make asynchronous operations wonderfully easy to implement. But getting stack trace looks like a completely synchronous operation to me. I cannot imagine making "return as a promise" even a neat special feature, lest forcing the user to always receive stack trace as a promise, requiring them to write several times more code and making logs harder to read (e.g. if you get stack trace as a promise, perform some different debug output synchronously, and then print the stack trace after exiting the stack you were supposed to examine).
Why did you make this decision? Can you please suggest any use cases where stack traces work well together with promises?
Reply to this email directly or view it on GitHub: https://github.com/stacktracejs/stacktrace.js/issues/113
septagram
I've been using version 0.6.0 for a while in one of the projects, with great success. However, just now I noticed that there's a newer version that relies on promises a lot, and that the top of the master branch only allows returning the stack trace as a promise.
I love promises myself and use them heavily. Promises make asynchronous operations wonderfully easy to implement. But getting stack trace looks like a completely synchronous operation to me. I cannot imagine making "return as a promise" even a neat special feature, not to mention forcing the user to always receive stack trace as a promise, requiring them to write several times more code and making logs harder to read (e.g. if you get stack trace as a promise, perform some different debug output synchronously, and then print the stack trace after exiting the stack you were supposed to examine).
I don't want to sound disrespectful, but I'm honestly at a loss here. Why did you make this decision? Can you please suggest any use cases where stack traces work well together with promises?