Here's that PR I mentioned yesterday.
Note that one of these commits ("Simplify") is purely some style stuff that I was thinking about as I was going through this. If you don't like it, I can revert that commit.
Test stack type remains a string after parsing
Use raw-stacktrace for retrieve the structured stack traces
Change how we retrieve the structured stack trace
Have you had a chance to look at this yet, @mattrobenolt?
Sorry, I did take a look, but got distracted by all of the other simplifications you did. :) Do you mind bringing this diff down to just what is affected, and if you want, submit another PR for the cleanup.
This reverts commit f1290bb.
Np, sorry about that - done!
Awesome, much better. I will look through this today. :) Thanks.
@azylman Can you fix this up to be merged? It looks good to me. I'll merge it in and do some more functional testing on my end to make sure that it handles everything correctly.
I'm also curious to see if it fixes up #38 or #39 by any chance.
Merge branch 'master' of git://github.com/mattrobenolt/raven-node
It should be good to go now - I ran the test cases again and they're still passing.
re: #38 and #39,
You can check to make sure someone else isn't overwriting Error.prepareStackTrace (a la Q) pretty easily after this change - checking that err.structuredStackTrace exists before sending it to parseStack. I had actually thought about doing that in this PR but 1) I wasn't aware of any other libraries that use Error.prepareStackTrace so wasn't sure it was worth it (though I am now aware of two - both Q and coffee-script do) and 2) wasn't sure how you'd want to handle that case so didn't want to do it without at least talking it over first.
Is structuredStackTrace a thing? Or did we just make that up? I haven't seen it before in any specs, granted none of this stuff is really a "spec". I'd feel more comfortable using a namespaced property, like: error.raven_structuredStackTrace, just to avoid the risk of collision.
structuredStackTrace is the same variable name that V8 uses for this. We could definitely attach it to a different property on the error instance if you'd like, but I just named it that since that's what V8 calls it. Would you like me to change it to something namespaced?
Welp, here goes nothing.
@azylman Mind checking out latest master? It appears good to me, just want another set of eyes on it for things you've been testing wiht just to double check.