Skip to content
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

rxjs-throw-error option to specifiy error names #64

Open
moeriki opened this issue Dec 7, 2018 · 7 comments
Open

rxjs-throw-error option to specifiy error names #64

moeriki opened this issue Dec 7, 2018 · 7 comments

Comments

@moeriki
Copy link

moeriki commented Dec 7, 2018

I have in an Angular project warnings for rxjs-throw-error on code like this.

throwError(new HttpErrorResponse({}))

I have worked with subclassing Error on other projects before as well.

Would you consider a PR adding an option to set error names.

eg.

"rxjs-throw-error": {
  "options": { "errorNames": ["Error", "HttpErrorResponse"] },
  "severity": "warn",
}
@cartant
Copy link
Owner

cartant commented Dec 7, 2018

Subclassing Error should be fine, as the rule uses the type information to determine whether the argument could be an Error. I guess HttpErrorResponse does not subclass Error if a warning is effected.

I'll give some thought to adding an option to make it a little more flexible.

@moeriki
Copy link
Author

moeriki commented Dec 7, 2018

Good to know.

For what it's worth, me throwing HttpErrorResponse is only in tests since Angular throws them otherwise. So I can easily disable them.

@NickLydon
Copy link

I've also come across this.
The signature of the class is: class HttpErrorResponse extends HttpResponseBase implements Error, which I would assume to work.

@cartant
Copy link
Owner

cartant commented Mar 19, 2020

implements is a TypeScript feature, though. Technically, it's still not an Error. To be an Error it would have to extend Error. Inheritance is the worst.

@NickLydon
Copy link

I've never implemented a ts-lint rule or used the typescript compiler api, so forgive me if this is dumb.
Error is defined as an interface:

interface Error {
    name: string;
    message: string;
    stack?: string;
}

Could you use this approach to check if the object implements this?

@cartant
Copy link
Owner

cartant commented Mar 19, 2020

@NickLydon

Could you use this approach to check if the object implements this?

Not easily. The check is done here and that function has only the type - it does not have the declarations:

  const baseTypes = type.getBaseTypes();
  if (!baseTypes) {
    return false;
  }
  return baseTypes.some(t => couldBeType(t, name, qualified));

I imagine that implemented interfaces are not included in what's returned from getBaseTypes. Whether they are available via some other method, IDK. Figuring out how to use these parts of the TypeScript API is a PITA. I will have a look later. Thanks for the suggestion, though.

@cartant
Copy link
Owner

cartant commented Mar 19, 2020

@NickLydon It's possible that this issue will be resolved with the changes in 4.29.2 - as that release includes an update to tsutils-etc that looks at implements clauses.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants