gleamunison/cli_result

One process-exit boundary for command results. Domain code returns data; only the CLI decides whether the process has succeeded.

Exit codes are a contract a script reads: 0 success, 1 refused (the command understood the request and declined it), 2 could-not-resolve (the request named something absent). Errors go to stderr so stdout carries only the result.

Values

fail

</>

pub fn fail(message: String) -> Nil

Fail on stderr. The doc comment above says stdout carries only the result, and fail_with_code already honours it — this one did not, so every command that declined through fail wrote its error to stdout: replay ... | jq piped a message, not a result. One boundary, one stream.

fail_with_code

</>

pub fn fail_with_code(code: Int, message: String) -> Nil

Fail with an explicit exit code, on stderr. Used where the code carries meaning: a caller can tell “refused” from “no such definition”.

finish

</>

pub fn finish(result: Result(Nil, String)) -> Nil

finish_coded

</>

pub fn finish_coded(result: Result(Nil, #(Int, String))) -> Nil

The same boundary for a command whose failure carries its own exit code: “absent” and “refused” are different answers, and the code is how a script reads the difference.

halt_failure

</>

pub fn halt_failure() -> Nil

Exit the process with the failure code and no message of its own: the caller has already said why. This is the raw form of fail below, for the commands that print their own diagnostic first.

print

</>

pub fn print(result: Result(String, String)) -> Nil

refused

</>

pub const refused: Int

success

</>

pub fn success(message: String) -> Result(Nil, String)

success_coded

</>

pub fn success_coded(
  message: String,
) -> Result(Nil, #(Int, String))

Success at the coded boundary: the result still goes to stdout, only the failure side carries a code.

unresolvable

</>

pub const unresolvable: Int