Skip to content

fix: add explanatory comments to empty catch blocks in browser finder#1848

Open
cxybd wants to merge 1 commit intobytedance:mainfrom
cxybd:fix/empty-catch-blocks-browser-finder
Open

fix: add explanatory comments to empty catch blocks in browser finder#1848
cxybd wants to merge 1 commit intobytedance:mainfrom
cxybd:fix/empty-catch-blocks-browser-finder

Conversation

@cxybd
Copy link
Copy Markdown

@cxybd cxybd commented Mar 13, 2026

🐛 Problem

Empty catch blocks in browser path finding functions silently swallow errors without explanation:

try {
  const path = which.sync(name);
  return path;
} catch (e) {}  // ❌ Why is this empty?

This makes the code:

  • Unclear whether error swallowing is intentional
  • Difficult to maintain and understand
  • Potentially confusing for new contributors

✅ Solution

Add clear explanatory comments to document the intentional behavior:

} catch (e) {
  // which.sync() throws when command not found - this is expected
  // when Chrome is not installed on the system. Continue trying other methods.
}

The comments clarify:

  1. Why the exception is caught (command not found)
  2. When this happens (browser not installed)
  3. What happens next (continue with other detection methods)

📝 Changes

Files modified:

  • packages/agent-infra/browser/src/browser-finder/chrome-paths.ts
  • packages/agent-infra/browser/src/browser-finder/firefox-paths.ts

What changed:

  • Added 3-line explanatory comments to each empty catch block
  • No functional changes - behavior remains identical
  • Improves code documentation and maintainability

Code diff:

  try {
    for (const name of list) {
      const path = which.sync(name);
      return path;
    }
  } catch (e) {
+   // which.sync() throws when command not found - this is expected
+   // when Chrome/Firefox is not installed on the system. Continue trying other methods.
  }

Statistics:

  • Files changed: 2
  • Lines added: 6 (comments only)
  • Lines removed: 0
  • Net change: +6 lines

🧪 Testing

  • TypeScript compilation: Passes
  • No functional changes: Behavior unchanged
  • Code quality: Improved documentation

Expected behavior:

  • Functions continue to work exactly as before
  • Returns null when browser not found
  • Upper layer BrowserFinder handles the null return appropriately

📊 Severity & Impact

Severity: Low-Medium (3-4/10)
Type: Code quality / Documentation improvement

Impact:

  • Better code clarity - Intent is now explicit
  • Easier maintenance - Future developers understand the logic
  • Prevents confusion - Won't be mistaken for unintentional bug
  • Follows best practices - Empty catch blocks should always have explanatory comments

Risk: None

  • Only adds comments, no logic changes
  • No breaking changes
  • No new dependencies

🔍 Related Issues

Addresses empty catch blocks that could cause confusion during code review and maintenance. Improves code documentation following best practices.

@netlify
Copy link
Copy Markdown

netlify Bot commented Mar 13, 2026

Deploy Preview for tarko canceled.

Name Link
🔨 Latest commit 49fceaf
🔍 Latest deploy log https://app.netlify.com/projects/tarko/deploys/69b3e028db85dd0008bba4f3

@netlify
Copy link
Copy Markdown

netlify Bot commented Mar 13, 2026

Deploy Preview for agent-tars-docs canceled.

Name Link
🔨 Latest commit 49fceaf
🔍 Latest deploy log https://app.netlify.com/projects/agent-tars-docs/deploys/69b3e028db85dd0008bba4ef

- Add clear comments explaining why exceptions are caught and ignored
- Improves code readability and maintainability
- Makes it clear that exceptions are expected when browsers are not installed

Severity: Low-Medium (3-4/10)
@cxybd cxybd force-pushed the fix/empty-catch-blocks-browser-finder branch from 517835e to 49fceaf Compare March 13, 2026 10:00
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

Successfully merging this pull request may close these issues.

1 participant