7 ms·

I don't speak for anyone else but I'm not using `unwrap` and `expect`. I understand the scenario you outlined but I've accepted it as a compromise and will `mat

I don't speak for anyone else but I'm not using `unwrap` and `expect`. I understand the scenario you outlined but I've accepted it as a compromise and will `match` on a map's fetching function and will have an `Err` branch. I will fight against program aborts as hard as I possibly can. I don't mind boilerplate to be the price paid and will provide detailed error messages even in such obscure error branches. Again, speaking only for myself. My philosophy is: the program is no good for me dead.

von_lohengramm 1y ago
> the program is no good for me dead That may be true, but the program may actually be bad for you if it does something unexpected due to an unforeseen state.
- pdimitar 1y ago
  Agreed, that's why I don't catch panics either -- if we get to that point I'm viewing the program as corrupted. I'm simply saying that I do my utmost to never use potentially panicking Rust API and prefer to add boilerplate for `Err` branching.
int_19h 1y ago
So what do you do in the error branch if something like out-of-bounds index happens? Wrap and propagate the error to the caller?
- pdimitar 1y ago
  Usually yes. But I lean much more to writing library-like code, I admit. When I have to make a decision on an app-level, it becomes a different game though. I don't have a clear-and-cut answer for that.
  - int_19h 1y ago
    This implies that every function in your library that ever has to do anything that might error out - e.g. integer arithmetic or array indexing - has to be declared as returning the corresponding Result to propagate the error. Which means that you are now imposing this requirement (to check for internal logic bugs in library code) onto the user of your library.
    - pdimitar 1y ago
      Well, I don't write as huge a code as this though, nor does it have as many layers. Usually I just use the `?` and `.map_err` (or `anyhow` / `thiserror`) to delegate and move on with life. I have a few places where I do pattern-matches to avoid exactly what you described: imposing the extra internal complexity to users. Which is indeed a bad thing and I am trying to fight it. Not always succeeding.

von_lohengramm 1y ago

> the program is no good for me dead That may be true, but the program may actually be bad for you if it does something unexpected due to an unforeseen state.

pdimitar 1y ago
Agreed, that's why I don't catch panics either -- if we get to that point I'm viewing the program as corrupted. I'm simply saying that I do my utmost to never use potentially panicking Rust API and prefer to add boilerplate for `Err` branching.

int_19h 1y ago

So what do you do in the error branch if something like out-of-bounds index happens? Wrap and propagate the error to the caller?

pdimitar 1y ago
Usually yes. But I lean much more to writing library-like code, I admit. When I have to make a decision on an app-level, it becomes a different game though. I don't have a clear-and-cut answer for that.
- int_19h 1y ago
  This implies that every function in your library that ever has to do anything that might error out - e.g. integer arithmetic or array indexing - has to be declared as returning the corresponding Result to propagate the error. Which means that you are now imposing this requirement (to check for internal logic bugs in library code) onto the user of your library.
  - pdimitar 1y ago
    Well, I don't write as huge a code as this though, nor does it have as many layers. Usually I just use the `?` and `.map_err` (or `anyhow` / `thiserror`) to delegate and move on with life. I have a few places where I do pattern-matches to avoid exactly what you described: imposing the extra internal complexity to users. Which is indeed a bad thing and I am trying to fight it. Not always succeeding.