AgentCompany/builtin-skills/software-engineer/clean-code/references/err-use-exceptions.md at b4e17cbd35ef1bb226ae099e63a2d69f9edd3d69

0 Fork 0

Files

T

ZacharyZhang-NY e74dafcd36 Silence render-disposed spam, unbreak bundled skills, drop board wake

Three independently ugly bugs that all fed the same log flood:

* Electron's `WebFrameMain.send` writes every "Render frame was disposed"
  to stderr via `console.error`. When the worker fans a second
  agent-event past a reloading renderer, we produced thousands of
  identical lines and stalled the main loop on stderr I/O. Added a
  `mainFrame.detached` guard so the send is short-circuited before
  Electron's own catch block fires, and installed a targeted filter in
  `suppress-warnings.ts` (now actually imported from the entry point)
  so the specific `console.error("Error sending from webFrameMain:"…)`
  noise never reaches the terminal. Any other payload still surfaces.

* `dispatchAgentMessage` accepted the human-reader sentinel as a wake
  target when an agent replied to `__board__` — `wakeAgentIfPossible`
  then called `db.getAgent("__board__")`, threw, and the dispatcher
  kept repeating on every send. Strip `HUMAN_SENDER_ID` at
  `resolveMessageWakeTargets`, and keep a defense-in-depth guard in the
  heartbeat so a stray caller (future automation fan-out) cannot
  reintroduce the crash.

* Pi's skills loader rejects any SKILL.md whose frontmatter `name`
  diverges from its parent directory. The four bundled `my-writing-style`
  copies declared `name: writing-style-skill`, so every install emitted
  a warning and dropped the skill. They also lived as orphan gitlinks
  (mode 160000 without .gitmodules), and the global `*.md` gitignore
  hid every other SKILL.md from version control. Fixed the frontmatter
  to match the dir, converted the dangling submodules to plain trees,
  and allowlisted `builtin-skills/**/*.md` so a fresh clone carries the
  catalogue instead of silently losing it.

2026-04-20 08:13:48 -04:00

3.0 KiB

Raw Blame History

title, impact, impactDescription, tags

title	impact	impactDescription	tags
Separate Error Handling from Happy Path	HIGH	reduces nested conditionals by 50-80% in exception-based languages	err, exceptions, error-handling, separation, result-types

Separate Error Handling from Happy Path

Error handling is important, but when it obscures logic, it's wrong. The core insight is separation: keep the happy path visible and error handling consolidated, regardless of which mechanism your language uses.

Incorrect (error handling obscures business logic):

if (deletePage(page) == E_OK) {
    if (registry.deleteReference(page.name) == E_OK) {
        if (configKeys.deleteKey(page.name.makeKey()) == E_OK) {
            logger.log("page deleted");
        } else {
            logger.log("configKey not deleted");
        }
    } else {
        logger.log("deleteReference from registry failed");
    }
} else {
    logger.log("delete failed");
    return E_ERROR;
}

Correct (Java/C#/Python — exceptions separate concerns):

public void delete(Page page) {
    try {
        deletePageAndAllReferences(page);
    } catch (PageDeletionException e) {
        logger.log(e.getMessage());
    }
}

private void deletePageAndAllReferences(Page page) throws PageDeletionException {
    deletePage(page);
    registry.deleteReference(page.name);
    configKeys.deleteKey(page.name.makeKey());
}

Correct (Go — explicit error returns with early return):

func (s *Service) Delete(page Page) error {
    if err := s.deletePage(page); err != nil {
        return fmt.Errorf("deleting page: %w", err)
    }
    if err := s.registry.DeleteReference(page.Name); err != nil {
        return fmt.Errorf("deleting reference: %w", err)
    }
    if err := s.configKeys.DeleteKey(page.Name); err != nil {
        return fmt.Errorf("deleting config key: %w", err)
    }
    return nil
}

Correct (Rust — Result type with ? operator):

fn delete(&self, page: &Page) -> Result<(), DeletionError> {
    self.delete_page(page)?;
    self.registry.delete_reference(&page.name)?;
    self.config_keys.delete_key(&page.name)?;
    Ok(())
}

The principle is language-agnostic: separate error-handling logic from business logic. The mechanism differs:

Java/C#/Python: try-catch with specific exception types
Go: explicit error returns with early return pattern
Rust: Result<T, E> with ? operator
TypeScript/Kotlin: Result types or exceptions depending on the domain

When NOT to use exceptions:

In Go, Rust, or other languages designed around explicit error values — use their idiomatic patterns instead
For expected business outcomes (e.g., "user not found") — consider returning Optional or a domain-specific result type rather than throwing
In performance-critical hot paths where exception overhead matters

Reference: Clean Code, Chapter 3: Functions and Chapter 7: Error Handling

3.0 KiB Raw Blame History

Separate Error Handling from Happy Path

3.0 KiB

Raw Blame History