3 ms·
> The main disadvantage of a Rust-?-like syntax for Go is you lose the ability to add context to the error You don't lose the ability to just by that syntax ex
by josephcsible 3y ago
> The main disadvantage of a Rust-?-like syntax for Go is you lose the ability to add context to the error
You don't lose the ability to just by that syntax existing. You could still do so by writing it out the long way like you have to do anyway today in Go.
- deleted 3y ago[deleted]
- grose 3y agoIndeed. What I meant is that compared to the pre-existing error handling, there are use cases it won’t fit. I am pro-? syntax. I think it would be useful even without being able to add context, but I’m also interested to see if there are solutions that could handle this for you.
- mseepgood 3y ago? is short syntax for something nobody should ever do. Why add special syntax for something you should literally never do?
- aldanor 3y agoAnd why should nobody ever do that?
- aldanor 3y agoThere's also helper crates like eyre simplifying the process of adding context even further (at the cost of type erasure): foo().context("oh no")?
- josephcsible 3y agoWhat do you mean by "at the cost of type erasure"? Isn't type erasure an attribute of a programming language and not something that a library has control over?
- aldanor 3y agoIn this case, it means your actual error will be packed and boxed someplace behind a smart pointer, its type will be lost (so you wouldn't be able to match on its specific variants downstream might you want to) but it will be still able to format itself to a string and will comply with std::error::Error trait.