A user queried their ticket queue and saw zero results. They assumed their workload was clear. In reality, the project ID was missing, the Notion API threw a validation_error, and the CLI silently caught the exception, returning an empty list to avoid printing a stack trace.

There is a widespread belief in software engineering that applications should “fail gracefully.” In the NTK CLI, this philosophy backfired spectacularly.

Make it Nicer = Make it Lie

To provide a smooth user experience, the code caught the API validation_error and returned []. The logic was: if the query is invalid, there are naturally no results to show, so returning an empty list is “graceful.”

It was a conscious choice. And it was a lie.

By swallowing the error, the CLI masked the fact that a database schema had changed or a project was entirely missing. The user had no idea the query itself had been rejected by the server.

Crash Loudly

Graceful degradation is for UI components, not for data retrieval. When a system asks for data and the underlying source rejects the request, the only correct action is to propagate that failure loudly.

Returning an empty list when an error occurs isn’t providing a good UX; it’s destroying trust. We removed the catch block. The CLI now crashes with a loud error when the API rejects a query. It’s uglier, but it tells the truth.

---

Next in the NTK series: how another broad catch block hid a fatal refactoring bug in Broad Catch Hides Reference Errors.

• #cli
• #api
• #ntk
• #engineering