3 ms·
I feel like you can't always handle every error. For instance if you're using a lot of third party libs that you aren't entirely familiar with, you may not be f
by ben_jones 10y ago
I feel like you can't always handle every error. For instance if you're using a lot of third party libs that you aren't entirely familiar with, you may not be familiar with every possible error a given method call can throw. To complicate the issue error messages are often cryptic, to the point where even if you do catch it it is an entirely pointless exercise.
In this situation I feel like try: except Exception as e: is infinitely better then a half-dozen if err != nils.
- JamesMcMinn 10y agoGo was essentially designed with the idea that you shouldn't ignore errors. However, if you really don't care about errors, you can simply ignore them: result, _ := thirdparty.ReturnsError()
- ketralnis 10y agoThat ignores the error but then silently does the wrong thing when one is thrown. That's different to exceptions where you bail the function instead of proceeding as if nothing went wrong
- clinta 10y agoMost of the time I end up writing if err != nil { return nil, err }. This seems better than a simple panic to me it allows the function to return, executing any deferred functions and doing any necessary cleanup. If I had any complaint it would be that go could offer some way to setup default handling that simply returns zero and error for any unhanded errors. I know the same thing can be done with try, catch finally but then you have the same problem of needing to know what errors may be returned so you can make sure an wrap that call in a try statement.