tisonkun commented on issue #27: URL: https://github.com/apache/datasketches-rust/issues/27#issuecomment-3666011425
That said, I totally agree to use `Result<T, E>` for known fallible cases. But I've experienced a `Result` everywhere policy applied once, even in cases where it shouldn't. In that story, the codebase ends up with `unwrap` everywhere and panic remains, even more subtle to debug. One reason here is that Rust doesn't have a global ancient `Exception`/`RuntimeException` class. It doesn't have `error` interface as in Go. So converting `ErrorTypeA` to `ErrorTypeB` among code paths is very awkward. You can use [`anyhow`](https://docs.rs/anyhow/latest/anyhow/trait.Context.html) but then you just know "something happen" rather than handling the Error when you can. One might consider creating a large error enum to cover all possible fallible cases in the codebase, but that would result in a scary big mess. Actually, I'm feeling the current `SerdeError` a bit over-designed already. Because what users can do for every variant is know that the data is illegal. It can have only one variant with a (debug) cause message to be printed. However, it's possible to design an `Error` type for a Rust library and use it library-wise. Apache OpenDAL's [`Error`](https://docs.rs/opendal/latest/opendal/struct.Error.html) does a good job of covering all common causes when accessing a storage. datasketches-rust may find such an Error, so most of the fallible methods can use that `Error`. Besides, Rust has more tools to handle fallible cases. For example, in the TDigest PR, I return `None` if the TDigest is empty on `rank`/`quantile`/`cdf`/`pmf`/`max_value`/`min_value`, while in C++ and Java impl, they throw an `SketchesStateException`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
