Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Use native Error instead of custom Error subclass. #17216
We originally created a custom subclass of
Please note that just because a given change might be observable, does not mean that it actually is breaking...
The thing that you are concerned with is where you were trying to see if a caught error was an
I just don't think this is a valid "thing to do" or care about. I also cannot find code on emberobserver.com codesearch that would fail with this change:
Out of all of the cases I reviewed (including
referenced this pull request
Nov 20, 2018
^^ Is my only concern.
I think @rwjblue approach to investigating risk here is quite good though, so I would like to see if we can proceed.
In general, I am more inclined to rip the bandaid off if possible, be we should be cognizant of any fallout. I believe your diligence is approaching sufficient, at-least for me.
@rwjblue Fair enough — forgive me for not adequately reading your analysis above about looking for (and not finding) any examples of code that would break in the wild.
My concern is companies that may have custom instrumentation that integrates with proprietary error reporting infrastructure. Examples of that may be hard to track down as they are unlikely to be open source. In this case,
Without litigating whether
If you don't think an RFC is appropriate, would you be open to making sure we include a mention of it in the release notes/blog post?