standardizing Error.stack or equivalent

[Christoph Martens]

Hey guys,

I wanted to chime in on the discussion about Error.stack standardization.
For my lil' game engine (http://lycheejs.org) I tried a couple things 
out how a custom Debugger (for a binary WebSocket protocol) can be 
implemented properly. I need to write an own debugger, because I'm using 
NodeJS + libsdl2 to cross-compile to Android and other platforms (like 
gaming consoles). So the problem here is that I also need several 
features that are not available in the Browser context, with the same 
API for Browser context environments. Also, bug reports with snapshots 
of the game are a huge thing as you could guess.


Four things I found out:

1. What purpose is Error.prepareStackTrace for? All tutorials do nothing 
more than returning the stack argument. You can't experiment with it, 
because it mostly crashes the VM in endless loops (at least on my RT 
Ubuntu) on coding mistakes. Can anyone explain it? Sorry for my bad 
Google Fu in this case.

2. For writing a Debugger, you may want to give hints to users that try 
to debug their own code. Like "Hey, it seems you wanted to access 
global.addEventListener, but this is no function and it's not 
available". I came to the result that such a hint implementation for 
generic properties and their logged accesses is not possible without 
Proxies (correct me if I'm wrong). I tried to have a loop running around 
a with block to determine those properties generically - and running the 
loop around it as long as it fails, but yeah - you could guess the 
hackiness level of that code.

3. A stack trace analysis tool might also want to auto-catch future 
occuring Errors and stop the VM. If I have a loop that has a try {} 
catch(e) { } finally {} block, and there is an Error happening inside 
the catch block (due to live coding and not being a perfect guy) - 
yeah... that sucks hard with Cache Reload stuff, because VM crashes 
before I can reload most times.

4. Why has an Error NO information about the file and line where it 
occured? Seriously, throwing a new Error() and tracing it, just for 
getting error.stack[0]'s information is like a complete design fail in 
my opinion. I think the Error should have the callsite information 
attached where it occured, with an optional getStacktrace() method 
attached to it (might be better for performance reasons?). That's the 
simplest API I could imagine; In my opinion the prepareStackTrace API is 
a bit overengineered and it is hard to trace multiple errors 
intelligently with it, as it's static. If it would be attached to the 
Error itself, it would ease up things for a custom debugger.


That's what I had in mind...


Cheers from Heidelberg,
~Christoph