Skip to content
This repository has been archived by the owner on Apr 12, 2024. It is now read-only.

provide isError and use it in place of instanceof Error #15868

Closed
2 of 3 tasks
graingert opened this issue Mar 29, 2017 · 4 comments
Closed
2 of 3 tasks

provide isError and use it in place of instanceof Error #15868

graingert opened this issue Mar 29, 2017 · 4 comments

Comments

@graingert
Copy link
Contributor

I'm submitting a ...

  • bug report
  • feature request
  • other (Please do not submit support requests here (see above))

Current behavior:

angular sometimes stringifies unhandled rejections, even if they're errors.

Expected / new behavior:

Angular should pass them on to the correct excetion handler

Minimal reproduction of the problem with instructions:
Difficult to reproduce

Angular version: 1.x.y
1.6.3

Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
Chrome

Anything else:
Provide angular.isError:

function isError(V) {
  var tagName = Object.prototype.toString.call(V);
  return (
    tagName === '[object Error]' ||
    tagName === '[object Exception]' ||
    V instanceof Error
  );
}

MIT from https://github.com/yefremov/iserror/blob/master/index.js

and use it wherever instanceof Error was used.

@gkalpak
Copy link
Member

gkalpak commented Mar 29, 2017

I don't think it makes sense to complicate things unless there is a reproducible, valid usecase, which makes it worth it.

@graingert
Copy link
Contributor Author

graingert commented Mar 29, 2017

this is an error passed from another context, eg another frame, or webworker

@gkalpak
Copy link
Member

gkalpak commented Mar 29, 2017

OK, sounds reasonable. Any idea where object Exception comes from? (Also, what about DOMExceptions?)

@gkalpak gkalpak modified the milestones: Backlog, Ice Box Mar 29, 2017
graingert pushed a commit to graingert/angular.js that referenced this issue Mar 30, 2017
@gkalpak
Copy link
Member

gkalpak commented Mar 30, 2017

Let's move the discussion to #15872.

graingert pushed a commit to graingert/angular.js that referenced this issue Mar 30, 2017
graingert pushed a commit to graingert/angular.js that referenced this issue Mar 30, 2017
graingert pushed a commit to graingert/angular.js that referenced this issue Mar 30, 2017
graingert pushed a commit to graingert/angular.js that referenced this issue Mar 30, 2017
graingert pushed a commit to graingert/angular.js that referenced this issue Mar 30, 2017
graingert pushed a commit to graingert/angular.js that referenced this issue Mar 31, 2017
graingert pushed a commit to graingert/angular.js that referenced this issue Apr 3, 2017
graingert pushed a commit to graingert/angular.js that referenced this issue Apr 3, 2017
graingert pushed a commit to graingert/angular.js that referenced this issue Apr 3, 2017
graingert pushed a commit to graingert/angular.js that referenced this issue Apr 18, 2017
graingert pushed a commit to graingert/angular.js that referenced this issue Apr 27, 2017
graingert pushed a commit to graingert/angular.js that referenced this issue Apr 27, 2017
12345678901234567890123456789012345678901234567890123456789012345678901234567890
Errors thrown from different contexts (such as an iframe or webworker) are not detected as Error
instances and handled accordingly.
This commit fixes it by introducing an isError() helper, that is able to correctly detect such
instances.

Fixes angular#15868
gkalpak pushed a commit that referenced this issue May 22, 2017
Previously, errors thrown from different contexts (such as an iframe or
webworker) were not detected as `Error` instances and handled accordingly.
This commit fixes it by introducing an `isError()` helper, that is able to
correctly detect such instances.

Fixes #15868

Closes #15872
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants