4 ms·
To add on; recover itself is a nice code-smell. If you're using recover, it's probably time to rewrite the func. I say this because Go forces you (minus just
by cremp 8y ago
To add on; recover itself is a nice code-smell.
If you're using recover, it's probably time to rewrite the func.
I say this because Go forces you (minus just ignoring with _) to error check; so panic's shouldn't happen to start with.
- echlebek 8y agoWell, panic should mostly be happening as a result of nil pointer deref, slice out of bounds, etc. You wouldn't want those types of operations to return error values.
- d0100 8y agoBut for those you can do a manual bounds & pointer check.
- skj 8y agoYour code is allowed to panic if there is a bug. For instance, the caller passed in a nil pointer where there needed to be actual data. Errors are for when the input (specifically the I/O) is wrong, a precondition isn't met, or some other error that doesn't mean there is something fundamentally wrong with your code. If to make the problem go away you need to fix the code, panic is OK.
- cpuguy83 8y agoThe problem is that it doesn't really force you to do error checks... and really most code I've seen doesn't really handle the error either so much as just bubble it up like a mini-exception.
- apta 8y ago> I say this because Go forces you (minus just ignoring with _) to error check; fmt.Println("foo") Where did golang force you to error check? How about (taken from here: (https://www.reddit.com/r/programming/comments/ak305l/goodbye... https://www.reddit.com/r/programming/comments/ak305l/goodbye...): r1, err := fn1() r2, err = fn2() if err != nil { return err }