handle errors properly in Axum | Sumiran Dahal

When you first build an API in Rust with Axum, error handling feels simple:

 async fn handler() -> Result<Json<User>, StatusCode> {}

But as your app grows, this quickly becomes messy:

Some errors are user mistakes.
Some errors are server bugs.
Some comef rom thrid-party libraries.
Some should NOT be logged.
Some should expose details.
Some absolutely should NOT.

So how do you structure this cleanly?

Let's walk through a real-world pattern.

The Problem We're Solving

Imagine a simple endpoint

POST /users

It:

Accepts JSON
Creates a user
Calls a third-party time library
Returns a JSON response

But:

If the JSON is invalid → client mistake
If the time library fails → server issue
We want to log internal errors
We don’t want to expose internal error details

That's the challenge.

Step 1 —Create a Proper Application Error

Instead of returning random status codes, we define one central error type:

enum AppError {
JsonRejection(JsonRejection),
TimeError(time_library::Error),
}

Now our whole application speaks one error language.

This is important.

You never want 20 different error types leaking into handlers.

Step2 —Make `?` Work Automatically

Inside the handler:

let created_at = Timestamp::now()?;

But wait...

Timestamp::now()` returns:

Result<Timestamp, time_library::Error>

Our handler returns:

 Result<_, AppError>

How does ? know what to do ?

Because we implemented

impl From<time_library::Error> for AppError

This is the magic

When ? sees an error, it automatically converts it using From.

Under the hood, this:

Timestamp::now()?;

Becomes:

match Timestamp::now() {
    Ok(val) => val,
    Err(e) => return Err(AppError::from(e)),
}

This is clean, powerful and idiomatic Rust.

Step 3 — Converting Errors into HTTP Responses

Now comes the most important pieces:

impl IntoResponse for AppError

This tells Axum: "If a handler returns

Err(AppError)
```, here's how to turn it into an HTTP response."

Inside, we seperate two world:

1. Client Errors (Bad JSON)
````rust
AppError::JsonRejection(rejection)

We:

Return the correct status
Return the correct message
Do NOT log it

Because the client messed up

Server Errors(Time LIbrary Failed)

AppError::TimeError(_)

We:

Return 500
Return a generic message
Do NOT expose details

Never leak internal errors to users.

That's production mindset.

Step 4 — Custom JSON Extractor

Axum’s default Json<T> returns plain text on error.

We want consistent JSON errors.

So we wrapt it:

#[derive(FromRequest)]
#[from_request(via(axum::Json), rejection(AppError))]
struct AppJson<T>(T);

Now JSON errors automatically becomes AppError

This keeps formatting consistent across the app.

The Full Flow (When Something Fails)

Let's say the time library fails:

Here's what happens:

Handler calls rust Timestamp::now()
It fails
? converts error -> rust AppError
Handler returns rust Err(AppError)
Axum calls rust into_response()
A 500 response is created
The error is inserted into response extensions
Middleware logs it
Client receives safe message

Client sees:

{
  "message": "Something went wrong"
}

Server logs:

error from time_library err=failed to get time

That's exactly what we want.

Why This Pattern Is So Good

This pattern gives you:

Centralized error handling
Automatic error conversion
Clean logging
Safe error responses
Seperation of responsibilites
Professional API structure

It scales beautifully.

The BIg Rust Lession Here

The real hero in this entire design is:

impl From<SomeError> for AppError

That single implementation unlocks:

Clean ? usage
Automatic conversion
Unified error handling
Less boilerplate
More readable code

Rust's error system isn't just strict.

It's composable.

Final Thought

Beginner Rust code looks like this:

if let Err(e) = something() {
    return Err(StatusCode::INTERNAL_SERVER_ERROR);
}

even i wrote this type of code, now I am going to understand and write clean code.

Professional Rust code looksl ike this: rust something()?

With:

Proper rust From implementations
A centralized error enum
A clean IntoResponse
Middleware-based logging

That's the difference between "it works" and "it's designed".

Thank you for reading this blog.

References: Axum Anyhow Error Example

Comments (4)