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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
