Improve script error reporting #1396

Closed
arantius opened this Issue Aug 10, 2011 · 5 comments

Comments

Projects
None yet
2 participants
Collaborator

arantius commented Aug 10, 2011

This issue is to track a particular idea I have. If the idea turns out to be no good, then there will be no fix/change for it.

Via any mechanism (likely a JS module), make a file with as little code as possible, all on one line, which actually calls evalInSandbox(). Given that the file has exactly one line, we can make more/better assumptions about the meaning of any line numbers we might get back from thrown/caught errors, and thus hopefully report them better and with less special case handling code.

arantius added a commit to arantius/greasemonkey that referenced this issue Aug 19, 2011

First-line-eval implementation.
Partially works.  The real problem is async callbacks.  Maybe doc'ed as it is, this is the best we can do?

Refs #1396

@arantius arantius closed this in d0aec33 Aug 19, 2011

Contributor

sizzlemctwizzle commented Aug 19, 2011

Couldn't we use the last two arguments for Components.utils.evalInSandbox detailed here?

So the call in modules/runScript.js would look something like:

Components.utils.evalInSandbox(code, sandbox, maxJSVersion, filename, 1);

We could loop through all the @requires and eval each one individually, that way those filenames and line numbers are preserved as well. Then finally we would eval the script. Is there some reason this wouldn't work?

Collaborator

arantius commented Aug 19, 2011

Wow, how did I miss that?

Requires are the issue. Today, they're all evaluated inside the same anonymous function and thus cannot be broken up. We tried taking it out in the past and it causes unpredictable issues.

@arantius arantius reopened this Aug 19, 2011

Contributor

sizzlemctwizzle commented Aug 19, 2011

Today, they're all evaluated inside the same anonymous function and thus cannot be broken up.
We could execute them all inside separate anonymous functions and bind their this to a single shared object using call. Of course this would mean we would have to decide that requires and the main script couldn't share local variables. I'd be willing to give this up for very accurate error reporting myself.

Or we could try executing the script and requires without an anonymous function and if we catch one of the tell-tail errors from one of them we could try re-executing it inside an anonymous function. I believe this is the method Scriptish uses.

Either that or we can just keep doing what were doing and use the fifth argument on evalInSandbox to force the line count to start at 1.

Collaborator

arantius commented Aug 19, 2011

On Fri Aug 19 15:47:57 2011, sizzlemctwizzle wrote:

Of course this would mean we would have to decide that requires and the main script couldn't share local variables.

That would be very much a breaking change. Pretty much every required
script today depends on this, no?

Collaborator

arantius commented Aug 22, 2011

Turned out to be a bit more involved than I first hoped, especially considering the scope issues with requires. So I added #1404 to do this bit, and for now we'll leave this issue solved as-is.

@arantius arantius closed this Aug 22, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment