hulla.dev

Start here

@hulla/control

Return typed success or failure values so callers can handle expected errors before transforming the result.

On this page

@hulla/control lets a function return success or failure as a value. Return Ok with the data or Err with the problem, then let the caller check which one it received.

TypeScript
import { err, ok, type Result } from '@hulla/control'

function findTitle(id: string): Result<string, Error> {
  return id === 'welcome' ? ok('Welcome') : err(new Error('Title not found'))
}

This is useful when a failure is part of the function’s contract, such as a missing record or invalid input. If callers already expect an exception boundary, keep throwing and use tcf() to convert that boundary. For ordinary internal work with no meaningful failure case, a plain return value is simpler.

Build the config checker to combine parsing, validation, and error reporting in one small command.

Edit the config and see where the deployment stops.

deploy.jsonEditable
{
  "replicas": 3
}

Deployment pipeline

  1. 1. Parse JSONOk
  2. 2. Validate configOk
  3. 3. Build deployment planOk

3 replicas ready for deployment

Runs @hulla/control locally. Thrown syntax errors and explicit validation failures both become results. Nothing is deployed.

You want to…Use
Run different code for success and failureisOk() or isErr()
Produce one value from either branchmatch()
Transform a payload and preserve its branchmap() or mapErr()
NeedStart here
Install the package and build a first resultQuick start
Construct, narrow, and inspect success or error valuesResults
Transform values while keeping the result branchChaining
Catch exceptions and rejected promises at an explicit boundaryAttempts

The result branch carries its own tag ('ok' or 'error' by default), so Result<string, string> remains unambiguous. Continue with the quick start to install @hulla/control and call a function that returns both outcomes.