3 ms·
> A function that returns something other than Result has to either call only infallible code or panic on error ...Or solve the problem. A library function tha
by pyrale 2y ago
> A function that returns something other than Result has to either call only infallible code or panic on error
...Or solve the problem. A library function that can be a source of issues and can't fix these issues locally should simply not be returning something that is not a result in that paradigm.
> since something can go wrong in most code
That is not my experience. Separating e.g. business logic which can be described cleanly and e.g. API calls which don't is a clear improvement of a codebase.
> the whole codebase converges as time goes to infinity on having Result everywhere.
As I said previously, it is pretty easy to pipe a result value into a function that requires a non-result as input. This means your pure functions don't need to be colored.
- quotemstr 2y ago> Or solve the problem. A library function that can be a source of issues and can't fix these issues locally should simply not be returning something that is not a result in that paradigm. People "solve" this problem by swallowing errors (if you're lucky, logging them) or by just panicking. It's the same problem that checked exceptions in Java have: the error type being part of the signature constrains implementation flexibility.
- ViewTrick1002 2y agoIn my experience an unwrap, expect or panicking function is a direct comment in code review and won’t be merged without a reason explaining why panicking is acceptable.