instead of save, and then I rescued and dealt with the invalid record case, giving the user a chance to fix and resubmit the form.
This is exactly the same kind of anti-pattern the Go community is talking about when they say, “return errors not exceptions”.
They don’t mean “nothing should panic or exit”, they mean “differentiate exceptions from errors”.
When I recovered from that invalid record error, that was a clear indication that I should have been using the non-exceptional save over the exceptional save!.
So back to Go.
If you know you’re going to panic anyway, there’s nothing “anti-Go-standards” about doing it immediately rather than passing up an error and letting the panic happen in main().
A good example might be config loading at program start.
Unless you have at least one caller of the LoadConfig() function that wants to (and can) recover, there’s no reason to pass back an error.
Rule of thumb: if you’re always going to panic or exit from a returned error, it’s perfectly reasonable to just do it immediately.
panic vs.
os.
Exit()One last thing.
If you fail via a call like log.
Fatalf(), it actually directly calls os.
Exit(), so you’re not even panicking.
.