-
Notifications
You must be signed in to change notification settings - Fork 443
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
panic() variant of Set() for config #64
Comments
also realized the client doesn't reconnect for some reason, nothing to report log-wise |
Are you using lookupd? If not, it uses a simple 15 second timeout after disconnection. I'd be fine adding |
If you want to panic on errors you can just do the following. I normally think of TL;DR; i'm not sure there is a strong enough reason for a second function to Set config values. if err := cfg.Set(...); err != nil {
panic(err.Error())
} |
Ah I thought the pattern was must return or panic, still a Go noob. I'm not using lookupd in this case, and I just remembered this morning that I've had errors from my local dev nsqd saying msg_timeout was too high so it can't be that, I'll sift through with --verbose |
@visionmedia you're right, that is the pattern (return or panic). @jehiah we kinda screwed this up in our Anyway, it is debatable whether having another set method would do the trick. I am sympathetic to the idea that the library should try to help you do the right thing as easily as possible, but having two methods might not be the path forward. I feel like, at one point, I had written Really, the golden rule is to always always always check returned errors when present. |
I just came across a similar issue trying to set I see there is also a public The reason I prefer this approach is that wrapping each What do you guys think? |
In #52 we re-exported Config values for backwards compatability, and to maintain a type safe way to set config values (or at least one that is caught at compile time). That leaves two ways to set config values; one is using the config struct directly which is ideal for Go code, and the second, through Because we allow the former it's possible to set out-of-range values on some items so I agree that error handling can be verbose, but it's the Go way, and I find the more I accept that up front I avoid unexpected states in the future. (I'll also say that was a particular style i was personally slow to adopt switching to Go from Python). To take direction from the stdlib, If |
I'm cool with the behaviour, just missed the error. I'll just |
I'm getting IO timeouts with
nsqd v0.2.28 (built w/go1.2.1)
for anything blocking for a second, which I'll need to fix anyway, but more importantly I didn't realize that Set() returns instead of a panic. I probably just don't have master with the msg_timeout support, but having a MustSet would be great for simple bootstrapping, dev error in my case. yay/nay?The text was updated successfully, but these errors were encountered: