ZacharyZhang-NY
e74dafcd36
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.
1.6 KiB
1.6 KiB
title, impact, impactDescription, tags
| title | impact | impactDescription | tags |
|---|---|---|---|
| Provide Context with Exceptions | HIGH | enables rapid root cause identification | err, context, messages, debugging |
Provide Context with Exceptions
Each exception should provide enough context to determine the source and location of an error. Create informative error messages that describe the operation that failed and the type of failure.
Incorrect (no context):
throw new Exception("Error occurred");
throw new RuntimeException("Failed");
throw new DataAccessException("Query failed");
// Stack trace alone doesn't tell you which order, which customer
catch (SQLException e) {
throw new RuntimeException(e);
}
Correct (rich context):
throw new OrderProcessingException(
String.format("Failed to process order %s for customer %s: %s",
orderId, customerId, "Insufficient inventory for item SKU-12345"));
throw new ConfigurationException(
"Cannot load configuration from " + configPath +
". Expected format: YAML. Check file permissions and syntax.");
catch (SQLException e) {
throw new DataAccessException(
String.format("Failed to insert order %s into table %s. " +
"Constraint violated: %s",
order.getId(), "orders", e.getMessage()),
e); // Preserve original exception
}
Include in exception messages:
- What operation was being attempted
- What data was involved (IDs, names, quantities)
- Why it failed (the specific error condition)
- Preserve the original exception when wrapping
Reference: Clean Code, Chapter 7: Error Handling