3 ms·
On the other hand, if you are writing library code or even a library-ish component of application code, having to write the same method a bunch of different tim
by TheSoftwareGuy 7y ago
On the other hand, if you are writing library code or even a library-ish component of application code, having to write the same method a bunch of different times is tedious. Ideally, the language would be designed so that there is one sane way of propagating errors, which can be easily either handled or propogated.
I am quite a fan of Rust's solution, with Result<T> types and various macros/methods which can do the commmon stuff for you
- wvenable 7y agoIn this case, it's the difference between what is an is not an error. Only one of those situations is an error. I agree having to write the same method a bunch of times is tedious but that is usually not the case. Most situations have clear intentions. It's much more likely in framework APIs where there are a bunch of non-task-specific operations. I find the whole manual propagation of errors, even with a lot of helpers, to just be tedious boilerplate. Most of the time I literally don't care about the error -- I want to crash my app, log the error, and alert me and the user. I don't need to propagate the potentially limitless number of errors possible in any non-trivial application.