wrapping javascript errors to exceptions

[DartBot]

This issue was originally filed by @bp74

---

I noticed a few revisions like r8103 where you try to wrap javascript errors to exceptions by looking at the message. This is a good idea but wont work on non english operating systems. If you run javascript on a german OS, the message is not "is undefined" but it is "ist undefiniert".

[peter-ahe-google]

Thank you, that is a good point.

---

Added Area-Dart2JS, Triaged labels.

[DartBot]

This comment was originally written by ngeoffray@google.com

---

cc @kasperl.

[kasperl]

We may have to wrap all JS exceptions we cannot understand in a general UnknownJsException or something like that. Not pretty.

[peter-ahe-google]

We can also force a null pointer exception and try to deduce the error message.

This would be a last resort, I want to investigate the objects in IE and FF to see if there are other ways to identify the error.

[peter-ahe-google]

Alternatively, we remove ClosureArgumentMismatchException, ObjectNotClosureException, and NullPointerException from the core library.

I have always believed that these classes all are implementation subclasses of NoSuchMethodException that the VM use to give better error messages.

The problem is that most of the co19 tests are checking for the subtle differences between these exceptions. I don't think the co19 tests would be worse if they cannot distinguish NullPointerException from NoSuchMethodException. I have always believed that what is important is that an exception is thrown, not the precise details, from a "conformance" perspective.

From a usability perspective, we should try to make as detailed exceptions as possible, but some browser simply doesn't provide enough information. However, I don't think a sane developer would care if the exception is NullPointerException or NoSuchMethodException, he cares that the error message is good.

[peter-ahe-google]

I have provoked a "null pointer exception" in Firefox. I get an instance of TypeError that has only three properties:

["message", "fileName", "lineNumber"]

As far as I can tell, there is no additional information but matching on the "message" property or punning by having all these exceptions be a NoSuchMethodException.

[peter-ahe-google]

Added this to the M1 milestone.

[peter-ahe-google]

Issue #4703 has been merged into this issue.

[peter-ahe-google]

On IE, it seems like we are looking for error code 438, facility 10.
See: http://msdn.microsoft.com/en-us/library/aa264511(v=vs.60)

This error code can be obtained using: JS('int', '#.number & 0xffff', ex).
See: http://msdn.microsoft.com/en-us/library/hc53e755(v=vs.94).aspx

Safari doesn't seem to localize JS exceptions, but I haven't tested it on iOS yet.

Firefox remains the big problem.

---

Set owner to @peter-ahe-google.
Added Accepted label.

[dgrove]

this looks great for IE. We should apply these and revert the English-specific tests for IE asap (we can definitely get the CLs out Monday Pacific Time). Wish there was an FF solution...

---

cc @efortuna.
cc @rakudrama.

[kasperl]

Removed this from the M1 milestone.
Added this to the M2 milestone.

[kasperl]

Removed this from the M2 milestone.

[kasperl]

Added this to the M2 milestone.

[peter-ahe-google]

Bumping priority: my second most starred M2 bug.

---

Removed Priority-Medium label.
Added Priority-High label.

[peter-ahe-google]

Removed this from the M2 milestone.
Added this to the M3 milestone.

[peter-ahe-google]

Issue #7545 has been merged into this issue.

[peter-ahe-google]

This is also causing problems in chrome.

[peter-ahe-google]

Thinking more about issue #7545: I think it may be unrelated and a side-effect of our new interceptor implementation. So I don't think we have this issue in Chrome after all, and I'll reopen issue #7545.