Why does InvokeError have from_anyhow instead of implementing From<anyhow::Error>?

[CrendKing]

InvokeError has from_anyhow, which converts an anyhow error to itself. It is useful, so that user can call an internal functions that returns anyhow error from a command function. However, it still requires an explicit map_error(InvokeError::from) at the end of every fallible command. Why did tauri decide to not implement From<anyhow::Error> so that the conversion can be implicit?

[adamhp]

Currently struggling with this myself! Would love to have the clean syntax from the implicit conversion.

[FabianLars]

Not an actual answer to the "why" since I wasn't involved in the linked change, but i always thought that you're not supposed to use InvokeError in commands yourself. It looked more like a tauri internal thing which is exposed because it is part of the public api (and needed by those who don't use the command macro).

So from that POV, not having From implementations make sense to prevent unexpected/"hidden" behavior. -> That said, not 100% familiar with the macro etc, so i'm not sure if that would even have direct impact but since InvokeError is what the commands actually return in the end i'd imagine so 🤔

[CrendKing]

In that case, I'll avoid using InvokeError directly. Thanks!

[JonasKruckenberg]

This is not by design, but a consequence of Rust's rules around implementing traits for types from 3rd party crates.

If you look at the code

You will notice we are implementing From<T> for InvokeError for all types that can be serialized. This makes total sense as the requirements around commands is that all parameters and return types (including errors) must be serializable/deserializable. So far so good.

Now if we were to try to add another impl

impl From<anyhow::Error> for InvokeError {
   fn from(value: anyhow::Error) -> Self {
      todo!()
   }
}

You will notice the compiler complains. This is because anyhow::Error doesn't not currently implement Serialize but it might start to anytime in the future
This would then break our code, since we would now have two From implementations for the same type (the generic T would now also match anyhow::Error)
As a consequence the compiler wouldn't know anymore which impl to choose and compilation would fail.

This is why we have the rather verbose from_anyhow and from_serde_json methods.

If you're familiar with Rust RFCs you might have noticed that this sounds and awful lot like specialization and indeed this would solve our issue, as the compiler would now accept our two From impls, simply choosing the more specific one.

[aminya]

I have published anyhow_serde as a drop-in replacement for anyhow with serde support.
https://github.com/aminya/anyhow_serde

[dependencies]
anyhow_serde = "1.0"

This adds serde implementation for the error to serialize/deserialize the error.

This allows the user to pass around the error types across the communication boundaries in apps such as Tauri without needing to convert the types. That means the ? operator can be used for Tauri commands, and any code that uses anyhow:Error can become a tauri::command without any modification.

https://tauri.app/develop/calling-rust/#error-handling

With this feature

#[tauri::command]
fn my_custom_command() -> Result<(), anyhow_serde::Error> {
  std::fs::File::open("path/that/does/not/exist")?;
  Ok(())
}

Without this feature: each function should be migrated away from Anyhow to be usable:

#[tauri::command]
fn my_custom_command() -> Result<(), String> {
  std::fs::File::open("path/that/does/not/exist").map_err(|e| e.to_string)?;
  Ok(())
}

[FabianLars]

mind opening a PR for that to our docs? as an easier alternative for the thiserror instructions for when simple errors are enough.

[alexanderflink]

@aminya Thank you! Does anyhow_serde work for Tauri v2? When trying out your example:

#[tauri::command]
fn my_custom_command() -> Result<(), anyhow_serde::Error> {
    std::fs::File::open("path/that/does/not/exist")?;
    Ok(())
}

#[cfg_attr(mobile, tauri::mobile_entry_point)]
pub fn run() {
    tauri::Builder::default()
        .plugin(tauri_plugin_opener::init())
        .invoke_handler(tauri::generate_handler![my_custom_command])
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

I get:

the method blocking_kind exists for reference &Result<(), anyhow_serde::Error>, but its trait bounds were not satisfied
the following trait bounds were not satisfied:
anyhow_serde::Error: Into<InvokeError>
which is required by Result<(), anyhow_serde::Error>: tauri::ipc::private::ResultKind
Result<(), anyhow_serde::Error>: IpcResponse
which is required by &Result<(), anyhow_serde::Error>: tauri::ipc::private::ResponseKind (rustc E0599)
hint: Error originated from macro call here
hint: Error originated from macro call here

I am new to Rust and Tauri, but it seems like Into<InvokeError> is not implemented for anyhow_serde::Error?

[aminya]

mind opening a PR for that to our docs? as an easier alternative for the thiserror instructions for when simple errors are enough.

Sure, I'll open a doc update PR.

@aminya Thank you! Does anyhow_serde work for Tauri v2? When trying out your example:

Thanks for the report. The serialize feature was not enabled by default. I just pushed a patch to fix it.

[dependencies]
anyhow_serde = "1.0.101"