You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
NOTE: In many scenarios, invoking a panic will actually be preferable to indicate that there is an error check missing.
I cannot think of a situation when this is not the case. Basically golang users should always check for errors. Returning noop empty struct basically asks for trouble and the user might not instantly realize that imported library function works not as expected. Fail as soon as possible. If there is an error, all other parameters should be ignored by the user.
The text was updated successfully, but these errors were encountered:
I don't necessarily disagree... I think that I'm more in favour of defensive program, than it seems that the lanugage developers of Go intended. I prefer to avoid panics and nil references.
the user might not instantly realize that imported library function works not as expected
Similar, the user might not realise a panic could happen and this ends up crashing a critical system at some point.
I think my opinion of this is that, the general advise is to avoid using panic, other than in startup / setup. So, why wouldn't we want to avoid a potential panic everywhere else in the code?
I hope you understand, I'm not trying to be stubborn ☺️ I just want to make sure we get each of our points across, I'm completely open to changing my opinion on this.
I cannot think of a situation when this is not the case. Basically golang users should always check for errors. Returning noop empty struct basically asks for trouble and the user might not instantly realize that imported library function works not as expected. Fail as soon as possible. If there is an error, all other parameters should be ignored by the user.
The text was updated successfully, but these errors were encountered: