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

feature request: always-throw functions detect in null check #16546

Closed
zh99998 opened this issue Jun 15, 2017 · 3 comments
Closed

feature request: always-throw functions detect in null check #16546

zh99998 opened this issue Jun 15, 2017 · 3 comments
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed Too Complex An issue which adding support for may be too complex for the value it adds

Comments

@zh99998
Copy link

zh99998 commented Jun 15, 2017

currently null check can detect throw, such code will works.

        const x = localStorage.getItem('test');
        if (!x) {
            throw 'error'
        }
        console.log(x.length);

but when throw was wrapped in a function, it fails. TS2531: Object is possibly 'null'

class Example {
    throw(something = true) {
        if (something) {
            throw 'error';
        } else {
            throw 'another';
        }

    }

    main() {
        const x = localStorage.getItem('test');
        if (!x) {
            this.throw();
        }
        console.log(x.length);
    }
}

now throw() will always throw an exception in any condition, it's better if this could be detected

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Jun 15, 2017

You can instead return this.throw() if you make its return type never to get something like this.

But it's not currently possible to signal that a function invocation completely changes the control flow graph, and I don't know if we ever will be able to.

@DanielRosenwasser DanielRosenwasser added Too Complex An issue which adding support for may be too complex for the value it adds Design Limitation Constraints of the existing architecture prevent this from being fixed labels Jun 15, 2017
@zh99998
Copy link
Author

zh99998 commented Jun 15, 2017

coule we simply make all code after never be unreachable ?

class Example {
    throw(): never { ... }
    main() {
        this.throw();
        console.log(1); // <- make this `Unreachable code`.
    }
}

@mhegazy
Copy link
Contributor

mhegazy commented Aug 29, 2017

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

@mhegazy mhegazy closed this as completed Aug 29, 2017
@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed Too Complex An issue which adding support for may be too complex for the value it adds
Projects
None yet
Development

No branches or pull requests

3 participants