Hook When your Domo CodeEngine automation silently assumes success and moves on to the next step, you're not building a workflow — you're building a time bomb. Here's how to design functions that fail loudly and correctly.
Why It Matters
The difference between returning False and raising an exception is not stylistic — it's architectural. Returning False means every caller must remember to check the return value; raising an error means execution stops and the failure propagates up the stack whether or not the caller was written carefully. In automation workflows, an unhandled silent failure can cascade: you might "successfully" complete five downstream steps against an account that was never actually created. Getting this right also forces you to reason about two distinct failure modes: a malformed request that returns a 401, versus a valid request that returns an empty list — those require different responses from your code.
What You'll Learn
- Understand why
raiseandreturn Falseare not interchangeable — and when each is correct - Design custom exception classes that carry the response object, URL, and error message for richer debugging
- Build validation logic into route functions so unexpected API shapes are caught at the boundary
- Distinguish between "the API returned nothing" and "the API returned an error" as separate cases worth handling separately
- Structure CodeEngine functions so errors bubble up gracefully into Domo workflow automation
Designing CodeEngine Functions That Fail on Purpose
The core pattern shown here starts with a CodeEngineRequestError custom exception class, extended to accept not just a message string but also the response object and the request URL. This matters in practice: when something breaks inside a workflow at 2am, you want the error to tell you exactly which endpoint was called and what came back — not just "something went wrong."
The validation approach builds assertions directly into route functions. Before processing a response, you check that the shape matches what you expect. If the API returns a 401, that's a different branch than an empty list — and both are different from a well-formed response with unexpected fields. Each of those cases deserves an explicit raise, not a return False that a caller might ignore.
One concrete heuristic from the walkthrough: if a successful API call can legitimately return an empty collection (e.g., a query that matches no records), then [] is a valid result and should not be treated as an error. But if your function contract says "return an account object," and the API returns nothing, that's a broken assumption worth raising loudly.
The domolibrary patterns shown in _base.py apply this consistently — every request wrapper validates the response and raises a typed exception on failure, so callers can either handle specific error types or let them propagate into the workflow engine's error handling layer.
