Comment by nothrabannosir | Hacker News Reader

Comment by nothrabannosir | Hacker News Reader

Parent Full thread

> The package author means the error will be nil when the secret is 32 characters long; he doesn't mean you can completely ignore checking it.

But that's exactly what will happen. This comment will lead to ws, _ := gowork.NewServer("32 character secret"). Which is a worse situation than a panic(). I understand the normal rule for this, but "a foolish consistency..". In this case, the init value being 32 long can be compared to "the init value must be non-nil." A lot of non-error APIs will panic() if you pass nil, even in the stdlib.

Doing panic() here will lead to less room for error and confusion, in my opinion. Especially because the error is explicit and loud (panic()), it's worth considering breaking the rules for.

If a developer is frequently ignoring returned errors, then they have larger problems and it's their fault. Panic was not added to assist lazy programmers. Even though some API has solidified, an author could later add different return errors. Heck, if that function was calling other functions with returned errors, then the list of possible unique errors increases greatly. You should never ignore an err because you think you know the possible reasons.

The package author should modify the phrasing of that comment.

Thanks for the feedback (both of you!) - when writing this, I envisioned a use case where the secret was static within the application, so it is easy enough for the developer to check their secret is 32 characters and not have to bother with checking that particular error. I didn't use panic because although a non 32 character secret puts my library in an unrecoverable state, it doesn't mean the application implementing the library is also in an unrecoverable state, hence why it returns an error instead of panicing.

Also, in terms of the top comment in this chain, the work server (master) never gets work from the workers, the workers push completed work back to the server, maybe this isn't clear within the current docs. All communication between the worker and server has to be coordinated by the application implementing the library.

Reply on news.ycombinator.com