Web Inspector: DOM exceptions should be more human readable

• Component: Web Inspector
• Status: ASSIGNED ---

[Brian Weinstein]

Bug 6745 covered human readable DOM exceptions in the Inspector/JavaScript Console on exceptions that were thrown during the execution of JavaScript on the page. This is the main place exceptions will be thrown, but it misses two cases that are also useful.

1) If a developer calls console.log() on a DOM exception:

try {
    document.appendChild();
} catch (e) { console.log(e); }

2) if a developer writes code in the interactive console that invokes a DOM exception:

> document.appendChild()


Both of these cases would benefit from human readable DOM Exceptions, and this bug is to track both of these.

[Brian Weinstein]

Created attachment 41451 [details]
Log the description when a DOM Exception is logged

[Eric Seidel (no email)]

Comment on attachment 41451 [details]
Log the description when a DOM Exception is logged

Seems that this test would be clearer w/o using console.log.

Do you really want to log all of the constants on the exception, or are you just trying to log the description?

A script-test may be a better choice for this style of test, since there you could use "debug()" easily for printing like this.

Ideally a test should carry test expectations in it instead of just dumping data, however that may not be possible/appropriate for this particular test.

Sad that Exceptions don't have any sort of base class.

Is "description" covered by any ECMA spec?

r- since the test is so hard to read with all the extra console.log linenumber output.

[Eric Seidel (no email)]

http://trac.webkit.org/wiki/Writing%20Layout%20Tests%20for%20DumpRenderTree has information on how to write script-tests if you're interested.

[Brian Weinstein]

(In reply to comment #2)
> (From update of attachment 41451 [details])
> Seems that this test would be clearer w/o using console.log.

What do you recommend instead? Ah, I see below you recommend debug(), I'll try that.

> Do you really want to log all of the constants on the exception, or are you
> just trying to log the description? 

All I'm interested in was the description, but I thought the other things could be useful, I'll just log the description.

> A script-test may be a better choice for this style of test, since there you
> could use "debug()" easily for printing like this.

I'll look at that and upload a new patch.

> Ideally a test should carry test expectations in it instead of just dumping
> data, however that may not be possible/appropriate for this particular test.

That can be done if I just want to log exceptions.

> Sad that Exceptions don't have any sort of base class.
> 
> Is "description" covered by any ECMA spec?
> 

No, this is a developer feature so the developer can get a readable description of the exception fired through the Inspector.

> r- since the test is so hard to read with all the extra console.log linenumber
> output.

Understood, I'll make it a cleaner test. Thanks!

[Brian Weinstein]

Created attachment 41609 [details]
Patch w/ Better Test - Addresses Eric's Comments

[Eric Seidel (no email)]

Comment on attachment 41609 [details]
Patch w/ Better Test - Addresses Eric's Comments

You could use:
shouldBeEqualToString("e.name", "NOT_FOUND_ERR")
to make parts of the test self-documenting.

Obviously the description stuff might vary more between browsers and you may want to leave as just "debug()"

The change looks OK as is, but using shouldBe or shouldBeEqualToString would be nicer.

[Brian Weinstein]

Committed original patch in r49222, rolled out in r49224 because description can't be exported because it conflicts with NSObject. About to upload a patch that renames to explanation.

[Brian Weinstein]

Created attachment 41624 [details]
Change from description to explanation

[Sam Weinig]

Comment on attachment 41624 [details]
Change from description to explanation

I don't think we should make this change since I don't think adding unnecessary JS API is a good idea.  Instead, we should just route the DOM exception information up to the inspector and do the special behavior there.

[Adam Barth]

Comment on attachment 41609 [details]
Patch w/ Better Test - Addresses Eric's Comments

Cleaning up pending-commit.

[Rob Colburn]

Old bug.  What's the status here?

[Radar WebKit Bug Importer]

<rdar://problem/19281490>

[Radar WebKit Bug Importer]

<rdar://problem/19281620>