-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot inherit Error #12581
Comments
@aluanhaddad In |
That is not true.
Please read one of those dozens of issues. It discussed at length. |
Shouldn't this bug be marked as a blocker for the 2.1 milestone? Looks like a serious issue to me. My projects are completely broken when switching to 2.1 because class MyError extends Error {
public constructor(message?: string) {
super(message);
}
}
try {
throw new MyError("Custom error");
} catch (e) {
if (e instanceof MyError) {
// Handle custom error <-- TypeScript 2.0 correctly ends up here
} else {
throw e; // <-- TypeScript 2.1 and 2.2 ends up here
}
} So now all custom errors are only instance of On the other hand it's nice that no special magic is needed any longer in the constructor to get error message and stack trace working in the custom error but breaking When removing the typescript-specific markup in the code and running it in a browser directly then the browser also correctly ends up in the instanceof block. So TypeScript 2.1 and newer compiles correct ES6 code into broken ES5 code. In TypeScript 2.0 this was working fine. Maybe instead of fouling around with the wrong class MyError extends Error {
public name: string;
public stack: string;
public constructor(message?: string) {
const error = super(message);
this.message = error.message;
this.stack = error.stack;
}
} |
@kayahr Me too! And it wasted my whole day. I think this is a compromising solution for losing properties. If you write code as your style, why not remove class MyError {
readonly name = 'MyError'
readonly stack: string
readonly message: string
constructor(message?: string) {
const error = new Error(message)
this.stack = error.stack
this.message = error.message
}
} |
The very fact that you have been having to perform these hacks just to capture the message and stack is an indication that the pattern is erroneous. These custom error classes were not inheriting from their specified parent class in even the most fundamental sense of the notion. They were just glorified tags that required not insignificant amounts of boilerplate, non idiomatic code to consume. Workarounds are available, but I'm just curious why a factory is insufficient? The factory can set up the necessary constructor and prototype links to minimize client breakage while you gradually move to a more reliable API.
|
I like @aluanhaddad's suggestion of using a factory function of some sort. Otherwise, I'm marking this as a duplicate of #12123. This is an intentional breaking change and documented here. Sorry about the inconveniences you may have encountered. |
The test code as follow:
The compile result Between typescript version
2.0.6
and2.1.1
is different:The
2.0.6
emit code as follow:And the
2.1.1
version emits as follow:The execute result is different:
The text was updated successfully, but these errors were encountered: