706324 - Infer reasonable display names for anonymous functions

Status: RESOLVED DUPLICATE of bug 433529

(Core :: JavaScript Engine, defect)

Description

[Chris Leary [:cdleary] (not checking bugmail)]

I just saw:

http://stackoverflow.com/questions/7583878/function-name-in-stack-trace-of-spidermonkey

Seems like displayName could be a nice feature for use in debugging / generating backtraces. Is this known / interesting to us?

Comment 1

[Jim Blandy :jimb]

It's definitely of interest. Of course, we need to ensure that the debugger doesn't get snagged if someone changes displayName to a setter property, but that can be arranged.

Comment 2

[Jim Blandy :jimb]

For what it's worth, a debugger implemented using the new Debugger API could choose to display any sort of name it wants for a function. This could be implemented without engine changes.

Comment 3

[Chris Leary [:cdleary] (not checking bugmail)]

Yeah, but it seems like this a feature that would be used in engine output in general, no? i.e. if we were to display any kind of name-related message to the user we would canonically call into some kind of DisplayName helper?

Comment 4

[Jeff Walden [:Waldo]]

Calling into user code like that makes it pretty easy to change language semantics -- suddenly that TypeError you were going to throw ends up being something else.  I am wary of consulting the user much when it comes to generating error messages and the like.  See bug 633623.

Comment 5

[Chris Leary [:cdleary] (not checking bugmail)]

Good point: I think my experience with Python is that they silently squash errors that occur during the VM's user reporting process (i.e. stringifying an exception object throws an error, so they just display nothing), which can be quite confusing.

I guess another question is: why is the name property of functions non-writable?

Comment 6

[Jim Blandy :jimb]

(In reply to Chris Leary [:cdleary] from comment #5)
> Good point: I think my experience with Python is that they silently squash
> errors that occur during the VM's user reporting process (i.e. stringifying
> an exception object throws an error, so they just display nothing), which
> can be quite confusing.

Trying to figure out what to do in the debugger when the debugger code itself throws an exception was kind of tricky. We have an uncaughtExceptionHook, but what to do when *that* throws an exception? (Our answer was, you got your second chance and blew it, just terminate the code, as if you'd gotten a slow script abort.)

> I guess another question is: why is the name property of functions non-writable?

It's not specified by ECMAScript...

Comment 7

[Chris Leary [:cdleary] (not checking bugmail)]

So I suppose this is closeable as WONTFIX.

Comment 8

[Jim Blandy :jimb]

This really needs to be fixed, folks. Right now our debugger commonly produces stack traces that look like:

[unnamed function]
[unnamed function]
[unnamed function]

This is crap, and whether one introduces a content-visible property to do it is completely beside the point.

This is a high-priority debugger task, because it's a fundamental usability issue.

Comment 9

[Jim Blandy :jimb]

(In reply to Jim Blandy :jimb from comment #8)
> [unnamed function]
> [unnamed function]
> [unnamed function]

To be clear: these functions are things like:

Tabzilla.open = function ()
{
    ...
}

To not display "Tabzilla.open" there is willful ignorance.

Comment 10

[Josh Matthews [:jdm]]

Relevant literature and art: Naming Anonymous Javascript Functions (http://johnjbarton.github.com/nonymous/index.html)

Comment 11

[Jim Blandy :jimb]

(In reply to Josh Matthews [:jdm] from comment #10)
> Relevant literature and art: Naming Anonymous Javascript Functions
> (http://johnjbarton.github.com/nonymous/index.html)

Woot! Thanks!

Comment 12

[Josh Matthews [:jdm]]

Is this just a dup of 433529, since work is actually being done there?

Comment 13

[David Bruant]

I'd say it is a duplicate