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

compilerOptions.useUnknownInCatchVariables introduces by #967 #952

Open
stefanpenner opened this issue Aug 27, 2021 · 0 comments
Open

compilerOptions.useUnknownInCatchVariables introduces by #967 #952

stefanpenner opened this issue Aug 27, 2021 · 0 comments

Comments

@stefanpenner
Copy link
Collaborator

stefanpenner commented Aug 27, 2021

re: compilerOptions.useUnknownInCatchVariables introduces by #967

Do we:

a) prefer to keep this disabled
b) update our code to correctly handle catch (e: unknown) {


I like (b) ... but it is more work, for example:

TS docs suggest e instanceof Error unfortunately, especially with more then one vmcontext there can be more then one error instance, and more technically today we duct-type these caught variables, changing them to a subclass model may not always be possible / work / etc.

One approach (type guard):

isWhatWeWant(e: unknown) : e is { code: string } {
  //... implementation
}

catch (e) {
  if (isWhatWeWant(e)) {
    if (e.code === 'ENOENT') {
       // do stuff
    } else {
       // do other stuff
    }
  } else {
    throw e; // we have no clue what is up
  }
}

Another approach: catch(e: any) { } loose and goosy

There are other approaches, WDYT?

@stefanpenner stefanpenner changed the title compilerOptions.useUnknownInCatchVariables introduces by #951 compilerOptions.useUnknownInCatchVariables introduces by #967 Sep 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant