Hacker News new | past | comments | ask | show | jobs | submit login
Tell HN: My first day of Advent of Code ended with some sourness
6 points by CameronNemo 8 days ago | hide | past | web | favorite | 4 comments
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






Can 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

(Not a Rust expert.)


This is exactly what I was missing... thank you!


The 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.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: