Native error handling upate

[eglove]

I want to check if this plugin is still being updated. I think it's a great plugin, with a great idea.

"This means that built-in functions that might throw exceptions are not yet linted. I'm working on a feature for that..."

This would have to be a hardcoded list. I wrote a plugin rule of my own that does this, but it's very naive and incomplete. It's the first plugin I wrote and frankly I don't know what I'm doing. :)

https://github.com/eglove/eslint-plugin/blob/master/src/rules/handle-native-error.ts

I'm looking at return signatures with TS to make sure you can use things like lodash attempt() and my own attemptAsync().

Fail:

JSON.parse("")
fetch("")

Pass:

attempt(JSON.parse, "") // returns T | Error
attemptAsync(fetch, "") // returns Response | Error

And this is working on a very quick AI generated (but confirmed) list of JS methods that throw.

https://github.com/eglove/eslint-plugin/blob/master/src/util/native-throw-methods.ts

If this plugin is being updated, I'd like to know an update on your own implementation. I would love to start with an incomplete list and contribute.

[Akronae]

Hi Ethan,
Thanks for your interest.
It's nice you're writing your own plugin, it's always a valuable experience to work with AST.
The list that you were able to generate is indeed very narrow and seems oriented towards browser runtime.
I was not really able to have any good result with LLM, the fact is that there is no decent ressource on the open internet to my knowledge would explain why. (which is crazy when you think about it)

I've been thinking about directly looking at the source code of Node.js to identify the code that directly "throws" errors, but it's more complexe than I thought because of the size and the layers of the project.
One thing that I would consider now is actually looking at the tests, Node.js seems really well test covered (hopefully so), and I think it might be much more easier to just scan for all the assert.throws and assert.rejects calls to identify what are they exactly testing that they expect to throw. I guess it will never cover everything but it might give us a solid base.

[eglove]

Yeah, that's a good idea. I think it would be OK to get an as complete list as possible and bite the bullet on the fact that it may never be exhaustive.

I thought about looking at @types/node or TypeScript type definitions for vanilla globals and suggesting a PR for @throws comments. From there you can effectively do this:

https://typescript-eslint.io/rules/no-deprecated/

The nice part of that is you can specify the Error types much easier. But, I think it's largely the same problem. It's still a matter of finding what does and doesn't throw. I know this is something a lot of people want, so finding a way to properly warn people of throws would be huge. :)

[Akronae]

Hi @eglove,

Just layed out the foundations for native modules support in v1.4.0
It's basically using src/utils/native-throwing.ts
Going to check how to analyze Node source code to build a complete list of functions that can throw.

Let me know if you have any thoughts.

[eglove]

Amazing! @Akronae

May need to account for this style of ts parser options though:

eslint.config.js:

export default tseslint.config(...config, {
  languageOptions: {
    parserOptions: {
      project: true,
      tsconfigRootDir: "./tsconfig.json",
    },
  },
}

Error:

Error: ENOENT: no such file or directory, open 'C:\Users\glove\projects\project-builder\true'
Occurred while linting C:\Users\glove\projects\project-builder\src\build-project.ts:23
Rule: "exception-handling/no-unhandled"

Error: ENOENT: no such file or directory, open 'C:\Users\glove\projects\project-builder\true'
Occurred while linting C:\Users\glove\projects\project-builder\src\build-project.ts:23
Rule: "exception-handling/no-unhandled"
    at readFileSync (node:fs:448:20)
    at resolveTSAlias (file:///C:/Users/glove/projects/project-builder/node_modules/.pnpm/eslint-plugin-exception-handling@1.4.2_jiti@1.21.6_typescript@5.6.2/node_modules/eslint-plugin-exception-handling/dist/index.mjs:180:20)
    at getImportDeclaration (file:///C:/Users/glove/projects/project-builder/node_modules/.pnpm/eslint-plugin-exception-handling@1.4.2_jiti@1.21.6_typescript@5.6.2/node_modules/eslint-plugin-exception-handling/dist/index.mjs:205:12)
    at resolveImportedId (file:///C:/Users/glove/projects/project-builder/node_modules/.pnpm/eslint-plugin-exception-handling@1.4.2_jiti@1.21.6_typescript@5.6.2/node_modules/eslint-plugin-exception-handling/dist/index.mjs:264:15)
    at resolveId (file:///C:/Users/glove/projects/project-builder/node_modules/.pnpm/eslint-plugin-exception-handling@1.4.2_jiti@1.21.6_typescript@5.6.2/node_modules/eslint-plugin-exception-handling/dist/index.mjs:318:24)
    at resolveFunc (file:///C:/Users/glove/projects/project-builder/node_modules/.pnpm/eslint-plugin-exception-handling@1.4.2_jiti@1.21.6_typescript@5.6.2/node_modules/eslint-plugin-exception-handling/dist/index.mjs:327:20)
    at canFuncThrow (file:///C:/Users/glove/projects/project-builder/node_modules/.pnpm/eslint-plugin-exception-handling@1.4.2_jiti@1.21.6_typescript@5.6.2/node_modules/eslint-plugin-exception-handling/dist/index.mjs:402:15)
    at CallExpression (file:///C:/Users/glove/projects/project-builder/node_modules/.pnpm/eslint-plugin-exception-handling@1.4.2_jiti@1.21.6_typescript@5.6.2/node_modules/eslint-plugin-exception-handling/dist/index.mjs:378:24)
    at ruleErrorHandler (C:\Users\glove\projects\project-builder\node_modules\.pnpm\eslint@9.11.0_jiti@1.21.6\node_modules\eslint\lib\linter\linter.js:1084:48)
    at C:\Users\glove\projects\project-builder\node_modules\.pnpm\eslint@9.11.0_jiti@1.21.6\node_modules\eslint\lib\linter\safe-emitter.js:45:58
Process finished with exit code -1

Looks like this happens when trying to get tsconfig:

[Akronae]

Oh good catch, I improved this part that handles parserOptions certainly still not perfect, but it should work for you now on v1.4.3.

Concerning Node source code analysis I'm making progress should be coming soon.