Thanks for the PR, @kirkwaiblinger!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!

🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint.

✅ Deploy Preview for typescript-eslint ready!

Name	Link
🔨 Latest commit	d1bb0bd
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/66f9dbbca45b460008785289
😎 Deploy Preview	https://deploy-preview-10058--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 99 (no change from production) Accessibility: 100 (no change from production) Best Practices: 92 (no change from production) SEO: 90 (no change from production) PWA: 80 (no change from production) View the detailed breakdown and full score reports

To edit notification comments on pull requests, go to your Netlify site configuration.

☁️ Nx Cloud Report

CI is running/has finished running commands for commit d1bb0bd. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

Sent with 💌 from NxCloud.

This looks great!

I think the key clarification for me would be something explicit along the lines of “there is no safe way to narrow a value whose type you don’t know into something that’s safe to call”

Maybe it would also be valuable to suggest type assertion within the try/catch as a preferred workaround to suppressing the lint rule? like:

try {
  (maybeFunction as () => void)();
} catch (e) {
  console.error(
    'Function either could not be called or threw an error when called:',
    e,
  );
}

since this way, you still let no-unsafe-call check that it would be safe to call the function if it had the type you expect it to have

but I think as-is, the PR is a great improvement to the docs for this new case

@controversial Good suggestions! I've updated it, and pared down the extraneous information 👍

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.01%. Comparing base (a916ff2) to head (2a0cbf5).
Report is 23 commits behind head on main.

❗ Current head 2a0cbf5 differs from pull request most recent head d1bb0bd

Please upload reports for the commit d1bb0bd to get more accurate results.

@@            Coverage Diff             @@
##             main   #10058      +/-   ##
==========================================
+ Coverage   85.99%   86.01%   +0.02%     
==========================================
  Files         428      427       -1     
  Lines       14912    14892      -20     
  Branches     4332     4329       -3     
==========================================
- Hits        12823    12810      -13     
+ Misses       1744     1736       -8     
- Partials      345      346       +1