Unrelated operator overloading causes incorrect exceptions

[dgrove]

svn r1844

(related to issue #576 and issue #596)

class x {
  operator+(x) => 1;
}

foo() => -1;

main() {
  print(foo() + "bar");
}

running frogsh on this produces:

TypeError: Object -1 has no method '$add'
    at $add (evalmachine.<anonymous>:6:17)
    at main (evalmachine.<anonymous>:36:9)
    at evalmachine.<anonymous>:38:1
    at main (/Users/dgrove/repo/dart-bleeding/dart/frog/frogsh:23536:10)
    at Object.<anonymous> (/Users/dgrove/repo/dart-bleeding/dart/frog/frogsh:23918:1)
    at Module._compile (module.js:411:26)
    at Object..js (module.js:417:10)
    at Module.load (module.js:343:31)
    at Function._load (module.js:302:12)
    at Array.<anonymous> (module.js:430:10)

this problem occurs with other operators, as well - if you overload them and then use the operator invalidly, you'll get the wrong sort of exception.

the VM produces:

NoSuchMethodException - receiver: 'bar' function name: 'addFromInteger' arguments: [-1]]
 0. Function: 'Object.noSuchMethod' url: 'bootstrap' line:315 col:3
 1. Function: 'IntegerImplementation.+' url: 'bootstrap_impl' line:1463 col:32
 2. Function: '::.main' url: '/Users/dgrove/repo/dart-bleeding/dart/frog/y.dart' line:8 col:15

[rakudrama]

The stack traces are misleading. Node.js is reporting a JavaScript exception that has not been translated to a Dart exception. There is a comment:
    // TODO(jmesserly): setting the stack property is not a long term solution.
    // Also it causes the exception to print as if it were a JS TypeError or
    // RangeError, instead of using the proper toString.

You need to catch and print the exception to see what the type is from the view of the Dart program.
Issue #470 will make this difficult, but you can verify the type with (ex is NoSuchMethodException).
If you catch and re-throw, Node still seems to report the original exception for the reason above.

Translating the exceptions is hacky and JS implementation specific. It might be more portable to put O(methodNames) stubs on Object.

Question: is the VM exhibiting definitive behaviour?
It looks like it is throwing a NSME because of an implementation detail and I could imagine the runtime library throwing some other exception.

Or is addFromInteger part of the exported library?
(I can see that my class Polynomial might want to play with the regular number hierarchy but I am having more difficulty seeing how my Polynomial might have Complex coefficients.)
If so, must Frog fake the same receiver, method name, arguments?

[rakudrama]

Provided you catch and re-throw the exception, http://codereview.chromium.org/8694007/ makes the correct message appear.

[anders-sandholm]

Removed Area-Frog label.
Added Area-Dart2JS, FromAreaFrog labels.

[kasperl]

Added WontFix label.