1. There is a typed conversion between one type of error and another, which can keep context. 2. There are traits which can extend error types. 3. Backtraces can optionally be kept on (at a performance hit during errors of course).
I have a lot of code written that looks like this, using the excellent "failure" crate, which allows optionally to add context to any error:
file.seek(SeekFrom::Start(offset)) .context(format!("failed to seek to {} in file", offset))?;
You get explicit errors, minimal code, optional error context. It's pretty perfect.
These are clearly not intended to be dissertations on the topic.
However, i don't think anything you said changes their discussion, actually.
How does it not? It seems to me that OP revealed an alternative method of error handling (which is very cool I might add), exactly in response to Google's discussion on Rust's error handling.
If the discussion doesn't address this, then it seems reasonable to say it's incomplete, as its omission makes it appear they're not debating Rust at its strongest.
edit: paper->discussion
I also definitely don't feel a failure to go off and survey every random library that exists for rust makes a discussion "woefully incomplete" or that it isn't debating rust at it's strongest. The same treatment is given to all languages, including rust, go, etc.
The discussion is also about language features, and it discusses the language features.
https://www.reddit.com/r/rust/comments/7te8si/personal_exper...
What would you have wanted them to do instead?
The author starts by identifying the use of the wrong type. They then immediately blame it on their own documentation in the very next sentence.