Hacker News new | comments | show | ask | jobs | submit login

Absolutely. Your users aren't likely to be seeing a server-side process like this fail, though, so in this situation, seems fine.

As I said in the post you're replying to, a nicer error message would be a good thing.




> Your users aren't likely to be seeing a server-side process like this fail, though, so in this situation, seems fine.

Whoever maintains the server and runs the service is also my user, though, in the general case.

> As I said in the post you're replying to, a nicer error message would be a good thing.

Yeah - I don't mind if unwrap panics with a dev-oriented message as it's basically an assertion, but I guess I expected expect() (no pun intended) to give a more user-friendly error. Maybe the format of the panic! output could be changed to bring the message to the front and the technical details after that.


In the world of server systems programming once an organization gets beyond a certain size it's uncommon to have programmers administering server daemons or other server applications. Those folks are indeed users.


See my sibling comment to the above. By the time your software has matured enough that it's been deployed to non-developers, unwraps have no place in the code. It's not an error-handling strategy, it's just "// TODO: Add error handling" that the compiler understands.


Example code should be exemplary.


As I said elsewhere, exemplary of what? The concept, or robust error handling? Even with the latter, it's unclear what the _right_ error handling is without knowing what you're actually doing.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: