Skip to content

Error in catch clause should be unknown #26174

Closed

Description

Search Terms

catch unknown type

Suggestion

Today I had another situation where I would have wanted #13219, but a less complex feature that would have prevented the bug as well would have been if the error in catch clauses had the new unknown type instead of any, forcing me to narrow it down before accessing properties.

Ideally this would be the same for the Promise rejection type.

Use Cases

Making error handling more type safe. Currently any prevents type narrowing.

Examples

This is a real world example of a bug:

    let pipeline: Pipeline
    try {
        ;({ body: pipeline } = await buildkiteClient.post('organizations/sourcegraph/pipelines', {
            body: buildkitePipeline,
            json: true,
        }))
    } catch (err) {
        if (
            err.error &&
            Array.isArray(err.error.errors) &&
            err.errors[0] &&
            err.errors[0].field === 'name' &&
            err.errors[0].code === 'already_exists'
        ) {
            console.log(`Buildkite pipeline ${repoName} already exists, skipping creation`)
            pipeline = await buildkiteClient.get(`organizations/sourcegraph/pipelines/${repoName}`)
        } else {
            throw err
        }
    }

Very easy to miss in code review - it should have been err.error.errors. This is an error returned by a real API.

Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript / JavaScript code (with a flag)
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. new expression-level syntax)

Activity

  1. mhegazy commented on Aug 3, 2018

    @mhegazy
    Contributor

    This is only possible if #25720, #10715, #25172, and #21732 are implemented. otherwise it is a massive breaking change.

  2. donaldpipowitch commented on Oct 28, 2018

    @donaldpipowitch
    Contributor

    I'd love to see this as well. I just made a PR to get this for Reacts componentDidCatch (DefinitelyTyped/DefinitelyTyped#30068), because it would have prevented a real world bug in our code and looked for an equivalent issue for the native try/catch.

  3. added
    Awaiting More FeedbackThis means we'd like to hear from more people who would be helped by this feature
    and removed
    RevisitAn issue worth coming back to
    on Dec 20, 2019
  4. falsandtru commented on Jan 3, 2020

    @falsandtru
    Contributor

    I want to enable this change by a compiler option. Or want to declare only unknown type like catch (reason: unknow) { }.

  5. gerardolima commented on May 5, 2021

    @gerardolima

    I believe the default inferred type for catch (err) { } should be unknown, which it is, instead of any which is unsafe and highly discouraged. unknown is safer and provides better semantics; I really don't understand why this is not the default for tsc.

    please see: typescript-eslint/typescript-eslint#3348

  6. wbt commented on Dec 17, 2021

    @wbt
  7. added
    FixedA PR has been merged for this issue
    and removed
    SuggestionAn idea for TypeScript
    Awaiting More FeedbackThis means we'd like to hear from more people who would be helped by this feature
    on Apr 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    FixedA PR has been merged for this issue

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions