4 ms·
Tell HN: My first day of Advent of Code ended with some sourness
I learned a great deal about error handling in Rust as a result, however. So I consider it a win. Here is my final commit message of the day:
fix(2019/1): avoid unwrap
unwrap() panics on error, which is not my intention.
Rather, I wish to return a generic error result.
I use the std::error:Error trait as a boxed type here,
based on a thorough review of my error handling options.
The following information was helpful in identifying which
options are and are not viable for error handling in Rust:
https://doc.rust-lang.org/std/result/index.html
https://doc.rust-lang.org/book/ch09-00-error-handling.html
https://blog.burntsushi.net/rust-error-handling/
https://lukaskalbertodt.github.io/2019/11/14/thoughts-on-error-handling-in-rust.html
I am disappointed that I must forgo the functional paradigm
in order to properly bubble errors up to the caller.
Ignoring read/parse errors while summing lines is incorrect,
in this case.
If omitting IO errors and malformed lines is acceptable,
a functional style can be achieved with filter_map().
https://gitlab.com/cameronnemo/advent/commit/d3b78501d91502691d5cc6762001d4832c3bf494
- sophiebits 7y agoCan you not use the question mark operator inside the .map() callback to return a Result, something like this answer? https://stackoverflow.com/a/26370894/49485 https://stackoverflow.com/a/26370894/49485 (Not a Rust expert.)
- CameronNemo 7y agoThis is exactly what I was missing... thank you!
- username90 7y agoThe functional solution would be to parse the line in one .map statement and apply the formula in the next, not doing both in the same. Then you get more options for handling errors, like filtering between the map statements or bubbling them from there.
- w4tson 7y agoNot a Rust expert. Here are my solutions https://github.com/w4tson/advent-of-code-2019/blob/master/day01/src/main.rs https://github.com/w4tson/advent-of-code-2019/blob/master/da...