fail

Fail

Sometimes a handler discovers halfway through that the request can’t proceed — the user isn’t authorized, the resource doesn’t exist, the input is invalid. Threading Result types back through every layer of middleware and controller code is painful. fail.with(404) short-circuits everything by raising an Erlang exception that the rescue_crashes middleware catches and turns into a proper HTTP response. Think of it like Laravel’s abort().

Types

Rescue

</>

The rescue_crashes middleware needs to distinguish between a handler that completed normally and one that called fail.with(). This type makes that explicit — Ok wraps the successful response, Fail carries the HTTP status code that should be returned to the client.

pub type Rescue(a) {
  Ok(a)
  Fail(Int)
}

Constructors

```
Ok(a)
```
```
Fail(Int)
```

Values

with

</>

pub fn with(status: Int) -> a

Deprecated: Return a response with the appropriate status code directly (e.g. response.not_found(), response.empty(503)). The error_handler middleware renders the correct page from the status. The generated _or_fail variants now do this automatically.

The escape hatch for handlers that hit a dead end. Call fail.with(403) when a user tries to access something they shouldn’t, or fail.with(404) when a database lookup comes back empty. It raises an Erlang exception under the hood, so it never returns — the type signature -> a lets it fit anywhere without type errors.