5 ms·

Imagine that you try to open your washing machine while it is washing. Correctly, you will get an error that this is not possible because you would be drenched

Imagine that you try to open your washing machine while it is washing. Correctly, you will get an error that this is not possible because you would be drenched with water. In addition, with this crate, you will also get the information that this error was returned in washing_machine.rs:3562. Thanks, I guess? >That is, why wouldn't the '?' operator already give us this kind of important detail? It's just not very useful information to have, except for the original developer (when debugging)--and the latter is a minority use case. Rust doesn't make you pay for things you don't use. But for this feature Rust would need to add an integer (and possible alignment bytes) and a str reference every single time there is a "?" (there are a lot of those) and an error is constructed, also when not debugging. This crate requires you to add `#[wherr]` in order for it to change what `?` does--and you would only do that when debugging. That's nice.

imetatroll 3y ago
I don't have the opportunity (yet?) to develop professionally in Rust but in the other languages I use, I do tend to include filename + line number information in server logs so that I can immediately find where something went wrong. So I'm not questioning the why of adding these, but was wondering why '?' doesn't have a way to do this for us already.
yazaddaruvala 3y ago
Having the file and line number automatically added is quite useful for server logs - especially in production. Very, very few end up in front of an end user. Typically only in a CLI.
JoelJacobson 3y ago
Author of `wherr` here. I agree that you wouldn't always want to pay the extra cost for this information. However, I imagine real-world use-cases when it's preferable to pay that cost in production, allowing users to forward file and line information to the original developer via a bug report. Alternatively, indirectly, for instance via some company's customer support, that might ask the customer to include output from their program, which they in turn can let their developers analyse, who in turn can contact the developer of the library used, where the error originates from. Not having this information in production, means the original developer will need to try to figure out how to reproduce the error locally, which might be necessary anyway of course, but the effort will probably be less, given the file and line information. That said, I agree with you that the most likely use-case, is to enable this only when debugging, on a per-function basis, when needed.
simiones 3y ago
> In addition, with this crate, you will also get the information that this error was returned in washing_machine.rs:3562. Thanks, I guess? Yes, that's awesome. I can either dig into the code myself or at least forward it to the project and get a great pinpointed report (at least some of the time). Much better than searching for strings and trying to guess what was parametrized. This is definitely something that you would want in production/in customer deployments. The only reason not to want this is extremely tight optimization scenarios, where paying the cost of the larger error type is too much (or if you're returning errors on some hot path).

imetatroll 3y ago

I don't have the opportunity (yet?) to develop professionally in Rust but in the other languages I use, I do tend to include filename + line number information in server logs so that I can immediately find where something went wrong. So I'm not questioning the why of adding these, but was wondering why '?' doesn't have a way to do this for us already.

yazaddaruvala 3y ago

Having the file and line number automatically added is quite useful for server logs - especially in production. Very, very few end up in front of an end user. Typically only in a CLI.

JoelJacobson 3y ago

Author of `wherr` here. I agree that you wouldn't always want to pay the extra cost for this information. However, I imagine real-world use-cases when it's preferable to pay that cost in production, allowing users to forward file and line information to the original developer via a bug report. Alternatively, indirectly, for instance via some company's customer support, that might ask the customer to include output from their program, which they in turn can let their developers analyse, who in turn can contact the developer of the library used, where the error originates from. Not having this information in production, means the original developer will need to try to figure out how to reproduce the error locally, which might be necessary anyway of course, but the effort will probably be less, given the file and line information. That said, I agree with you that the most likely use-case, is to enable this only when debugging, on a per-function basis, when needed.

simiones 3y ago

> In addition, with this crate, you will also get the information that this error was returned in washing_machine.rs:3562. Thanks, I guess? Yes, that's awesome. I can either dig into the code myself or at least forward it to the project and get a great pinpointed report (at least some of the time). Much better than searching for strings and trying to guess what was parametrized. This is definitely something that you would want in production/in customer deployments. The only reason not to want this is extremely tight optimization scenarios, where paying the cost of the larger error type is too much (or if you're returning errors on some hot path).