3 ms·
An if err with some random one-liner in the err part is not error handling. You can’t reasonably handle an error condition on a local basis, that’s why excepti
by kaba0 3y ago
An if err with some random one-liner in the err part is not error handling.
You can’t reasonably handle an error condition on a local basis, that’s why exceptions (especially checked ones) are superior. They do the correct thing — either bubble up if it doesn’t make sense to handle them in place, or have them in as broad of a scope as it makes sense with try-catches. Oh and they store the stacktrace, so when an exception does inevitably happen in your software you will actually have a decent shot of fixing it instead of grepping for that generic error message throughout the program (especially if it’s not even written by you!). I swear people lie to themselves with all those if-errs believing they have properly handled an error condition because it took effort.
- arez 3y agoyes, that's exactly how I also think about Go's error handling. It was always praised the in the early days but it becomes more and more obvious that it's not a good way of handling errors, let alone reading code full of error returns and if err
- meling 3y agoI see this argument a lot, but error handling is also code that you probably want to read. Especially if you are debugging a problem. My experience is that exposing the error handling logic makes this easier. But I also like John Ousterhout’s suggestion to define errors out of existence where possible (A Philosophy of Software Design). But that requires more thinking than some developers like to deal with.
- preseinger 3y agocalling a function that can fail means you need to manage that condition inspecting the err value returned by a function call is in fact error handling the point of this design is to keep control flow "on the page" exceptions do not keep control flow "on the page"