ivan-pesenti
181 posts

ivan-pesenti
@ossandev
Hi! I'm an Italian guy who codes and plays football. Glad for what I've got and happy with people. Looking for software engineering challenges 😵

A lot of Go devs get taught a fake rule: never use panic. The advice is simple but it is also lazy. Panic is just a sharp tool that needs to be used correctly. The real advice is do not use panic for normal failure, use it when the program has reached a state that should not exist and cannot be handled in a sane way. If your code can recover, return an error. If your code is - broken, - your assumptions are false, - startup cannot continue, Basically, this can't be happen, if this happen, my data is corrupted, my application is not in correct state, etc. Then failing hard is cleaner than pretending everything is fine. Bad error handling is often worse than no error handling. People wrap impossible states in polite-looking error returns and push the mess upward, so now every caller has to act like a broken invariant is just another routine case. That makes code noisier and less honest. So a well-placed panic can say something important: this is not business logic, this is a bug, a bad configuration, or a state the program was never designed to survive. We do use panic in our codebase to catch corrupted state early: #L142" target="_blank" rel="nofollow noopener">github.com/VictoriaMetric…


I'm launching today a project that I've been thinking about the last 10 years. A blog about software internals. If you want to know more take a look to the welcome post (or the other 2 that are already published) internals-for-interns.com/posts/welcome/


































