3 ms·
This means you will have to write an if after every method call which is annoying and makes code less readable (source: had to write lots of ifs several days ag
by codedokode 2y ago
This means you will have to write an if after every method call which is annoying and makes code less readable (source: had to write lots of ifs several days ago while writing a C library. My code consists mostly of ifs with error handling, because almost every function - even encoding conversion - can fail. I think that if companies hired low-paid trainees just for the purpose of writing ifs they could save a lot).
- mrkeen 2y agoIf it's repetition, you can abstract it away.
- mightyham 2y agoThere are very few cases where you can abstract away error handling because it's extremely context dependent.
- bedobi 2y agoI don't mean to be uncharitable but no, that's not how it works. You pass the Either<Error, Foo> or Maybe/Option<Foo> around, usually to the edge of the system where you map, flatMap or fold it into something.
- codedokode 2y agoBut this is ugly, for example, if I have a square root function, I don't want it to accept Error.
- bedobi 2y agoNo function should accept error
- eyelidlessness 2y agoPresumably one of these applies: * You have a sequence of steps, and only care about a general error condition occurring somewhere in range of those; in which case, it makes sense to abstract something to treat those steps as a unit and collect any error from that * You don’t need to handle any errors directly, and wish to propagate them to the caller; in which case, doing so explicitly is better than not * You should handle the errors; in which case, complaining about that doesn’t make much difference