Do you want to request a feature or report a bug?
Bug.
What is the current behavior?
Sometimes (not always) the message
property of the error is logged as [object ErrorEvent]
. I followed the standard implementation of Raven in Angular as described here: https://docs.sentry.io/clients/javascript/integrations/angular/.
What is the expected behavior?
To see a normal error message.
Raven 3.17.0
Angular 4.3.1
Webpack build
Not using CLI
CDN version
Is there a definition of ErrorEvent
somewhere in the Angular docs? Apparently this is not "inheriting" Error
in the right way.
The issue could be in TraceKit's traceKitWindowOnError()
method, it doesn't seem to take into account that the message
argument could be an ErrorEvent
(see MDN docs)
@benvinegar There are some docs here on ErrorEvent
: https://developer.mozilla.org/en-US/docs/Web/API/ErrorEvent
Affected by this too, so are these users:
https://forum.sentry.io/t/reporting-object-errorevent/1807
[email protected] (but has been happening for a while on older versions too)
Angular 4.x
Using CLI
Same here with Ionic 3 and [email protected]
<script>
undefined.foo();
</script>
^ This in your html is logged in safari via sentry as [object ErrorEvent]
. Correct message would have been TypeError: undefined is not an object (evaluating 'undefined.foo')
.
We have an external script that injects code via script tag that tries to create an iframe, but thats blocked by safari. As the error originates from the injected script tag, sentry just reports [object ErrorEvent]
Another error from sentry reported as just [object Event]
is from the flowplayer. The flowplayer does
jQueryElement.trigger('error', [api, {code: 5}]);
You can reproduce it by embedding jQuery and just do:
$('div:first').trigger('error')
Sentry sees something like this
Sure thats not very serializable, but an error like error on element from jQuery - context <div class="foo><div class="bar" ...
would be much more helpful then [object Event]
Also affected by this.
@daangeerdink @jdelaune @rosslavery @tgensol could someone provide a the smallest possible code that could help me reproduce this?
@sod I just checked, and Safari 10.1.2 is providing correct message in the scenario that you mentioned above.
I personally can't provide a repro, because the errors are so opaque I can't discern which part of my codebase is throwing the error. I don't have any stack traces to work with, nor an error message to figure out if it's my code, or a 3rd party lib, etc.
Hopefully someone else has a simplified example they can provide, sorry I couldn't be of more assistance.
We are also having this problem. I have can share some data from the last 10 days (22k events of this type, 13k users). I hope it helps you to reproduce it.
@kamilogorek We have 2 millions errors of this type. I thought it was our problem, but we were unable to track it correctly.
I found the issue. ErrorEvent
is not being treated as an error by the isError
util function, which can be found here. For convenience, I'll paste the function definition also:
function isError(value) {
switch ({}.toString.call(value)) {
case '[object Error]':
return true;
case '[object Exception]':
return true;
case '[object DOMException]':
return true;
default:
return value instanceof Error;
}
}
I did a quick test in my console to see whether or not this function would return true for an ErrorEvent
, and it did not:
isError
is used in the captureException
method to determine whether the exception parameter is an error or simply a message. captureException
will send exceptions to the dashboard using captureMessage
if it thinks the exception is not _actually_ an error. In this case, Raven will not compute a stack trace or "process" the exception. It just sends it off as is.
Is there any reason we shouldn't update isError
to return true for ErrorEvent
objects?
Is there any reason we shouldn't update isError to return true for ErrorEvent objects?
Yes. Because it's not actually a descendent from Error
(it's a descendent of Event
). It doesn't have a stack
property, for example (AFAICT, playing around in the console). Which means it may not actually get processed correctly.
It would be great to see an example of how this error is generated live, so that we can figure how best to process it.
The constructor for ErrorEvent
takes an Error
, so you could easily handle them like so:
if (isErrorEvent(ex)) {
ex = ex.error;
}
You can see the construction definition here. In particular, look at the ErrorEventInit
hash. It's an optional parameter, so I guess the solution I posted above doesn't handle the case where an ErrorEvent.error
is undefined.
Sure, I believe this can be solved – I just meant that it is not as simple as just augmenting isError
to return true
.
I understand. I'll put up a PR in a few minutes.
Fixed in 3.19.x
Thanks @shcallaway! 👍
Seems like we are still getting this issue on 3.19.1
🤔
@PhilippSpo which browser is this event coming from? ErrorEvent
is not supported in some old mobile browsers and IE so we had to fallback to regular solution.
@kamilogorek Chrome 61.0.3163
I'm seeing it on Chrome 61 also. 😕 I'll try to look into it soon.
Thanks @shcallaway
Also happens on Safari 11.0, Mac OS 10.13
It looks like traceKitWindowOnError doesn't process correctly input parameters when 'message' parameter is an ErrorEvent object:
and 'ex' is undefined. Then, it invokes notifyHandlers with an object where 'message' field is an ErrorEvent, not string:
which, when strigified in _makeRequest, produces meaningless message.
Thanks for investigation @michal-rumanek, I'll try to handle this issue soon (don't have spare time this week).
@kamilogorek, any progress? ;-)
Hi, I am getting a lot of these errors [object Object]
.
Angular 4
Chrome 62.0.3202
Raven-js 3.20.1
Most helpful comment
I found the issue.
ErrorEvent
is not being treated as an error by theisError
util function, which can be found here. For convenience, I'll paste the function definition also:I did a quick test in my console to see whether or not this function would return true for an
ErrorEvent
, and it did not:isError
is used in thecaptureException
method to determine whether the exception parameter is an error or simply a message.captureException
will send exceptions to the dashboard usingcaptureMessage
if it thinks the exception is not _actually_ an error. In this case, Raven will not compute a stack trace or "process" the exception. It just sends it off as is.Is there any reason we shouldn't update
isError
to return true forErrorEvent
objects?