More idiomatic and ergonomic error handling

[d-k-bo]

Currently, all client methods return Result<T, LemmyErrorType>. The LemmyErrorType error type is suboptimal for users of the library for multiple reasons:

• it doesn't implement std::error::Error (although this could be fixed in a one-line PR to lemmy_utils), so it can't be used with eyre/anyhow and anything else that expects an impl Error or dyn Error without wrapping it in another error type
• it doesn't differentiate between HTTP errors and errors that are returned from the lemmy API
• in the case of HTTP errors, the original error isn't preserved (e.g. reqwest::Error)

Executable Example

#!/usr/bin/env -S cargo +nightly -Zscript
---
package.edition = "2024"

[dependencies]
lemmy-client = "1.0.5"
tokio = { version = "1.45.0", features = ["macros", "rt-multi-thread"] }
---

use lemmy_client::{
    ClientOptions, LemmyClient,
    lemmy_api_common::{
        lemmy_db_schema::newtypes::PostId,
        post::{GetPost, GetPosts},
    },
};

#[tokio::main]
async fn main() {
    http_error().await;
    lemmy_error().await;
}

async fn http_error() {
    let client = LemmyClient::new(ClientOptions {
        domain: "nolemmy.example.org".to_owned(),
        secure: true,
    });

    if let Err(e) = client.list_posts(GetPosts::default()).await {
        // Unknown("error sending request for url (https://nolemmy.example.org/api/v3/post/list)")
        println!("{e:?}");
    }
}

async fn lemmy_error() {
    let client = LemmyClient::new(ClientOptions {
        domain: "lemm.ee".to_owned(),
        secure: true,
    });

    if let Err(e) = client
        .get_post(GetPost {
            id: Some(PostId(123456789)),
            comment_id: None,
        })
        .await
    {
        // CouldntFindPost
        println!("{e:?}");
    }
}

---

I suggest that this crate returns a different error type instead that implements std::error::Error, provides access to an underlying error at least via Error::source() and at least provides some methods to check if the error is an HTTP error or an error returned by the API.

This could also be done using the widespread “error enum” pattern (which can be implemented using thiserror, but can also easily be written by hand).

Error Enum Example

#[derive(Debug)]
pub enum Error {
    #[cfg(target_family = "wasm")]
    Http(gloo::net::Error),
    #[cfg(not(target_family = "wasm"))]
    Http(reqwest::Error),
    Lemmy(LemmyErrorType)
}

---

P. S.: I think a lot could be implemented easier if this crate used reqwest for both WASM and non-WASM, although I don't know the tradeoffs between gloo::net and reqwest.

[dessalines]

This would probably be better to handle in the lemmy back-end, but I don't think there's any way around custom error wrapping if you want to convert lemmy's API error types into your own.

[SleeplessOne1917]

I second Dessalines on handling the errors: unfortunately, the errors the client uses comes from a crate from Lemmy's backend, which shoves every single possible error that can be returned by the API into one unwieldy god-enum. It's an issue that would require changing the error enum on the backend to adequately solve the problem.

Regarding the use of gloo-net for WASM: this is meant to keep the WASM bundle that gets sent to the browser smaller, since it uses the browsers built-in capabilities for making HTTP requests instead of implementing it entirely like reqwest does. I plan to move this behind a browser feature flag for the Lemmy 1.0 compatible release instead of always using it when targeting WASM since it's possible to use WASM in non-browser contexts.

[d-k-bo]

I think my previous post didn't convey my main issue with the current situation.

If the HTTP request itself fails, e. g. in case of a network error, the error of the underlying HTTP library gets stringified on the client side. This means that an application using this library has in this case no way to differentiate what actually happened. The only possible option is to show the raw error message to the user. This doesn't only harm app design, localization etc., it also prevents application logic like retrying after a short period in case of a network timeout.

[d-k-bo]

Regarding the use of gloo-net for WASM: this is meant to keep the WASM bundle that gets sent to the browser smaller, since it uses the browsers built-in capabilities for making HTTP requests instead of implementing it entirely like reqwest does.

In fact, reqwest wraps the browser APIs as well when targeting WASM. But you are right, the bundle size seems to be smaller when using gloo-net. I did a quick test comparing them and replacing gloo-net with reqwest resulted in additional 52 kB binary size (release build, opt-level = "z", using trunk).