Errors
Blyp error handling revolves around three pieces:
createError()for building and optionally logging aBlypErrorparseError()for hydrating unknown payloads orResponseobjects back into aBlypErrorHTTP_CODESfor reusable status presets and custom error families
Choose the right entry point
| Need | Use |
|---|---|
| Create a brand-new structured application error | createError() |
Normalize a failed fetch() response or foreign payload | parseError() |
| Reuse a status preset or define a shared domain error | HTTP_CODES |
Shared error shape
A BlypError can carry more than a message:
statuscodemessagewhyfixlinkdetails
That makes the same error useful for runtime logging, API responses, and operator-facing debugging.
Typical flow
- Build a first-party failure with
createError()or normalize an external one withparseError(). - Throw or return the resulting
BlypError. - Reuse
HTTP_CODESwhen the same pattern appears across multiple handlers or services.
What a BlypError looks like end to end
Code:
throw createError({
status: 402,
message: "Payment failed",
});What Blyp logs:
[ERROR] Payment failed
status=402 type=BlypErrorHTTP response body:
{
"status": 402,
"message": "Payment failed"
}parseError() output
const parsed = parseError(err);Result shape:
{
"status": 500,
"message": "Unexpected token in JSON",
"type": "SyntaxError",
"stack": "SyntaxError: Unexpected token...\\n at JSON.parse (<anonymous>)"
}