Skip to content
This repository has been archived by the owner on Mar 25, 2021. It is now read-only.

add rule to detect throwing of string literals #1878

Merged
merged 1 commit into from
Dec 18, 2016

Conversation

atscott
Copy link
Contributor

@atscott atscott commented Dec 15, 2016

PR checklist

  • Addresses an existing issue: #0000
  • New feature, bugfix, or enhancement
    • Includes tests
  • Documentation update

What changes did you make?

I've added a rule that detects when a throw statement has a string literal, which does not produce a proper stack trace. The suggested fix is to change throw 'string' to throw new Error('string'). I didn't see an existing issue for this, but can create one if needed.

@palantirtech
Copy link
Member

Thanks for your interest in palantir/tslint, @atscott! Before we can accept your pull request, you need to sign our contributor license agreement - just visit https://cla.palantir.com/ and follow the instructions. Once you sign, I'll automatically update this pull request.

Copy link
Contributor

@nchen63 nchen63 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you enable CircleCI on your fork?

@@ -0,0 +1,23 @@
let a = () => throw 'bla';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add tests for template string and template strings with replacement variables

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Enabled CircleCI, added tests and logic for handling template strings, and fixed errors from 'npm run verify'

export class Rule extends Lint.Rules.AbstractRule {
/* tslint:disable:object-literal-sort-keys */
public static metadata: Lint.IRuleMetadata = {
ruleName: "string-throws",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you rename to no-string-throw to be consistent with other names?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note, non-plural

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

}

class Walker extends Lint.RuleWalker {
public visitThrowStatement(node: ts.ThrowStatement) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indent width should be 4 spaces

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

`because only Errors produce proper stack traces.`,
options: null,
optionsDescription: "",
type: "typescript",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

type should be functionality

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@atscott
Copy link
Contributor Author

atscott commented Dec 18, 2016

I messed up my branch pretty badly in a bad merge and rebase squash. I think I got everything back to normal and addressed your comments.

@nchen63 nchen63 merged commit 501d4c0 into palantir:master Dec 18, 2016
@nchen63
Copy link
Contributor

nchen63 commented Dec 18, 2016

@atscott thanks!

@andy-hanson
Copy link
Contributor

Wouldn't it be better to have a type-based rule to check that anything thrown is an Error?

@nchen63
Copy link
Contributor

nchen63 commented Dec 19, 2016

I kind of went back and forth on this one. Yes, type checking would catch all cases and be simpler to implement, but it also requires --type-check and --project. My thought was that if a rule can capture 80% of the real world cases without the type checker, it's good enough. However, I'm open to changing my mind.

@adidahiya
Copy link
Contributor

I generally agree that lightweight syntactic checks that cover the majority of real-world use cases are useful to have in the core ruleset.

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

Successfully merging this pull request may close these issues.

5 participants