[webkit-dev] Improving DOM Exception console messages.

[Darin Adler]

On Oct 1, 2012, at 2:57 AM, Mike West <mkwst at chromium.org> wrote:

> Concretely, this might involve adding two properties to ExceptionBase: 'context' and 'totallySektitContext'

I think the naming here is critical.

The word “context” is an extremely bland and vague one that does not make it clear what this information is for, that it’s human readable, for programmers to look at and not for programs to inspect, and that the “secret” version is a version that’s OK for exposure locally to development tools and not for exposure to the web content itself, to protect privacy.

Further, “context” sounds like “the place where the exception happened” to me, rather than “detailed explanation of what failed from the point of view of the code that threw the exception”.

So we need different names. Perhaps detailedDescription and detailedDescriptionForLocalUseOnly? That second name is super-long so probably bad, and it doesn’t make the end user privacy aspect clear.

I’m sure someone else can come up with better names.

> At each setDOMException callsite, we'd have to provide some mechanism for setting one or both strings.

I’m interested in what this would be. I worry about creating two string objects every time, especially when the caller is not the DOM itself and will be simply destroying those strings without inspecting them.

> This might involve turning ExceptionCode enum into a struct containing the code and slots for two strings.

Seems like an acceptable basic approach, but will be a huge change covering tons of call sites. This is something we should be careful to do deliberately while thinking about and measuring the performance impact and readability impact.

Might want to change ExceptionCode into a class in a separate pass before we put additional data members into that class.

Using a simple integer for exceptions inside the DOM has kept the exception related code inside the DOM both simple and efficient; moving to a class does give us the opportunity to be clearer since ExceptionCode is a little confusing with confusing rules about how to use it. One of its confusing rules is that you are not obliged to initialize it if you don’t plan on looking at it; I presume we’d get rid of that rule if we made it more complex, so we’d probably be paying a bit of additional cost to initialize it at each call site that plans to ignore exceptions.

Longer term it’s probably best to not use the entry points that take ExceptionCode& much internally in the engine. Antti Koivisto has been arguing we should keep that to a minimum since often the public DOM idiom is not a good way for our code to work internally inside WebCore, so perhaps this is consistent with that direction.

-- Darin