New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 13 users

Issue metadata

Status: Fixed
Buried. Ping if important.
Closed: Apr 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocked on:
issue v8:2822

Sign in to add a comment

Issue 228909: custom Errors are reported as "Uncaught [object Object]"

Reported by, Apr 8 2013

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31

Steps to reproduce the problem:
1. Go to this url:
2. Look at the "result" panel.

What is the expected behavior?
Should see "MyError: foo" there. 

What went wrong?
I see "Uncaught [object Object]" there.

Looks like when an error is thrown which inherits from Error, when the error is reported to window.onerror or console or developer tools, something goes wrong when creating a string representation of the error object.

Did this work before? Yes I detected the issue on the 4 Feb 2013, Chrome 25.

Chrome version: 26.0.1410.43  Channel: stable
OS Version: OS X 10.8.3

I'm not familiar with the v8/Chromium codebase but my guess is that the problem is around here:

Comment 1 by, Apr 9 2013

There seems to be more going on here. The code OP posted seems relevant (instanceof check was removed) but then why isn't the toString working? toString of `Error` is something like "Error: [message]", certainly not "[object Object"].

This bug also occurs in the Windows version of Chrome.

My UA: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31

Comment 2 Deleted

Comment 3 by, May 11 2013

I can confirm this also occurs on a similar custom error class we're using:

See;a=blob;f=modules/ext.guidedTour.lib.js;h=cac98b07b05766eb659b3eaadb68314cf923b11f;hb=HEAD#l1220 (line 1220).

I was able to work around the bug by not inheriting from Error and using a custom toString that included the message and exception class name:

	gt.TourDefinitionError.prototype.toString = function () {
		return 'TourDefinitionError: ' + this.message;

Comment 4 by, Jun 14 2013

Reproducible on Windows 7, 64-bit, Chrome version 29.0.1537.0 canary

Comment 5 by, Jun 14 2013

Looking at the code OP linked to I believe the following is happening:

1. ObjectToString refers to Object.toString(), invoking ObjectToString on our object returns "[object Object]". Now looks what happens...
2. All if statements leading up to IS_OBJECT(obj) return false.
3. IS_OBJECT(obj) is true but "%GetDataProperty(obj, "toString") === ObjectToString" is false because we overrode toString()
4. IsNativeErrorObject(obj) returns false since we our error object isn't a native type.
5. Finally, the function invokes ObjectToString on our type, which returns [object Object]

This behavior seems to be by design. If an error occurs, the last thing you want to do is invoke user code which could trigger yet another error (hence the function name  "NoSideEffectToString".

What should happen? The line "IsNativeErrorObject()" should also check for subclasses of Error and invoke Error.toString() on them. Error.toString() is a safe function should it should be okay to invoke on our subclass.

I think fixing this issue is as simply as replacing:

if (IsNativeErrorObject(obj)) return %_CallFunction(obj, ErrorToString);


if (IsNativeErrorObject(obj) || obj instanceof Error) return %_CallFunction(obj, ErrorToString);

Comment 6 by, Jun 14 2013

If you don't care about instanceof, here is a simply workaround that produces a stack-trace that is almost correct (top stack element should be omitted):

function AssertException(message)
	"use strict";
	var result = new Error(message); = "AssertException";
	return result;

Comment 7 by, Jul 22 2013

Data point: this issue affects Handlebars errors. It took me a while to track this down as the root cause.

Comment 8 by, Aug 1 2013

Labels: -OS-Mac OS-All
Status: Assigned
Thanks for the detailed error report.

I'll take a look at this, since I'm currently poking at some other pieces of 'window.onerror'.

Comment 9 by, Aug 1 2013

It looks like this is only broken for the particular style of inheritance you're running with. I'll poke at V8 a bit to see if supporting 'subclass.prototype = new Superclass();' is reasonable, but workarounds include:

  subclass.prototype = Object.create(superclass.prototype);

and closure's 'goog.inherit' (

Comment 10 by, Aug 2 2013

Blockedon: v8:2822

Comment 11 by, Aug 6 2013

Fix landed as It should roll into Canary in some reasonable period of time.

Comment 12 by, Jul 15 2015

Labels: -Cr-Content-JavaScript Cr-Blink-DOM

Comment 13 by, Apr 18 2016

Blockedon: -v8:2822 v8:2822
Status: Fixed (was: Assigned)
Assume this was fixed.

Sign in to add a comment