JS-Interpreter icon indicating copy to clipboard operation
JS-Interpreter copied to clipboard

Bug report about error message

Open ayahito-saji opened this issue 1 year ago • 9 comments

New bug report. I found that error messages behave incorrectly in the following case:

var err = new TypeError("default");
alert(err.message); // default
err.message = "changed!"
alert(err.message); // changed!
throw err; // Uncaught TypeError: default

changed! should be printed, somehow default is printed. Thank you.

ayahito-saji avatar Feb 28 '24 17:02 ayahito-saji

When run on https://neil.fraser.name/software/JS-Interpreter/ in both uncompressed and compressed modes, I get changed!. Can't recreate. Can you double-check?

NeilFraser avatar Feb 28 '24 17:02 NeilFraser

Could you please open the developer's console? You should see Uncaught TypeError: default.

ayahito-saji avatar Feb 28 '24 17:02 ayahito-saji

Whoa, it works fine (changed!) on Firefox, it fails (default) in Chrome. Was not expecting that!

NeilFraser avatar Feb 28 '24 17:02 NeilFraser

Wow, that is strange behavior. I tested it with Chrome and Node.js and it failed. The syntax for assigning stack traces was non-standard. It may be that different browsers behave differently.

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Error/stack

ayahito-saji avatar Feb 28 '24 17:02 ayahito-saji

Perhaps the code that generates the stack trace from the error message is in the wrong place. The stack trace should be generated at the time of the throw, not at the time the error is generated, right? https://github.com/NeilFraser/JS-Interpreter/blob/master/interpreter.js#L2290C3-L2305C45

ayahito-saji avatar Feb 28 '24 17:02 ayahito-saji

This is getting weirder and weirder. Take this screenshot from Chrome's console: Screenshot 2024-02-28 at 19 45 41 Here the exact same commands are entered twice. The difference is that the lines above are copied and pasted into the console, whereas the lines at the bottom were manually typed. And the results are different.

NeilFraser avatar Feb 28 '24 18:02 NeilFraser

Filed a bug with Chrome console: https://issues.chromium.org/issues/327467399

Let's put this issue on ice until we can get Chrome to be consistent (one way or the other). Firefox behaves as expected.

@cpcallen : Chris you might find this entertaining.

NeilFraser avatar Feb 28 '24 20:02 NeilFraser

This is indeed entertaining.

Perhaps the code that generates the stack trace from the error message is in the wrong place. The stack trace should be generated at the time of the throw, not at the time the error is generated, right?

Although the ECMAScript spec has never mentioned anything about the .stack property on Error objects, as far as I am aware all JS runtimes set this at the time the Error object is created, not when it is thrown.

The reason for this is that otherwise it would break this very useful pattern:

try {
  mightThrow();
} catch (e) {
  if (e instanceof RecoverableError) {
    recoverFrom(e);
  } else {
    throw e;  // Rethrow unrecoverable error.
  }
}

So the code in JS Interpreter looks correct to me, but there does seem to be something funky going on with Chrome.

cpcallen avatar Mar 01 '24 16:03 cpcallen

The behavior of Chrome is very weird. Thank you for reporting the bug.

And thank you for the clear explanation of when the error is generated.

ayahito-saji avatar Mar 04 '24 11:03 ayahito-saji

The bug in Chromium has been fixed by the team (their comment was "Amazing bug!😂").

I've tested it using the current release of Chrome and I believe this bug has been resolved. Please reopen if there's still an issue. Thanks!

NeilFraser avatar Aug 27 '24 12:08 NeilFraser