Hacker News Reader

Comment by noitpmeder | Hacker News Reader

I find it really interesting that the author's example assumes that the read() and send() calls are the ones you need to worry about w/r/t exceptions. To me, the parse() call seems the most volatile -- what guarantees are there that the bytes you just read are parsable?

I usually code my programs assuming the system will work (reads/writes/sends). While I know this isn't guaranteed, it's a lot more likely my filesystem will work than that a file is assured to contain parsable data.

View on HN

> To me, the parse() call seems the most volatile -- what guarantees are there that the bytes you just read are parsable?

None, which is why, in Rust, parse never throws an exception on a parsing error, and instead, returns a Result<Ok=T,Err=ParseError>, which is an ADT with either an Ok(T), which means parse succeeded, or an Err(ParseError), which means that an error happened, and contains state about where, etc.

See its documentation: https://doc.rust-lang.org/stable/std/primitive.str.html#meth...

The author isn't talking about this, probably cause its not the point of the article, but in Rust, you can't avoid handling parsing errors. If you want to actually get the value, you need to handle the possibility that an error happened. The programming model does not give the user a choice here.

it’s a blog about async, and especially cancelation. parse presumably doesn’t do any I/O. read/send are the interesting bits because they hit the network, where latency is practically unbounded. a first approach at cancelation might be to make precisely those I/O routines cancelable via (say) error injection, in such a way that none of the non-I/O code ever needs to care specifically about cancelation. so read/send is where the “interesting” cancelation logic lives or hooks into.

> assuming the system will work (reads/writes/sends)

I encounter these issues quite commonly. Permissions, being in the wrong dir, buggy setup that forgot to create directories or copy files etc.

Isn't the `read()` and `send()` in rust concerned with those less-exceptional exceptions as well?

I totally get these issues, and one definitely should be aware of them when designing a system. It just feels a bit weird to treat these as the points where exceptions emerge and not the parsing of input data.

Could totally be an artifact of the example that was chosen to prove a point, it's just what jumped out at me.

Usually in Rust, parsing would never cause panic (or your parsing library is very wrong), parser will just return error for unparsable input.

> It just feels a bit weird to treat these as the points where exceptions emerge and not the parsing of input data.

I understand this. It does make sense when seen as an artifact of the educational nature, though.

If the article wanted to explain about exceptions in the parser, the author had to explain the domain as well. Whereas we all are familiar with the exceptions in the file-io-domain already.

> I find it really interesting that the author's example assumes that the read() and send() calls are the ones you need to worry about w/r/t exceptions.

I didn't read it that way. In my view, the article is explaining a mental model where async code & panics are similar/related in a possible abstract mental model. He's using that snippet of code which from an async perspective, one could reasonably expect that the file or network IO is worth async waiting on but parsing is not.

But I don't think the author assumes parsing couldn't raise an exception since he states at the beginning: "If the parse function or the send function were to throw an exception, whatever data had just been read (and maybe parsed) would be lost.".

Its more that in Rust, async cancellation will occur exactly at await points, which are generally when you do IO.

Reply on news.ycombinator.com