3 ms·
Yes, not my proudest moment. To be honest, I wasn't really sure what to with all the err's.
by Spiritus 12y ago
Yes, not my proudest moment. To be honest, I wasn't really sure what to with all the err's.
- buro9 12y agoThe only issue I'd really be strict about is that you're not doing anything with the errors. Specifically, you've: 1. Encountered an error 2. Detected it 3. Printed it But you've continued execution, and some of those errors are clearly not going to let you continue cleanly. If you couldn't call git on the command line (i.e. it is not installed), then what are you going to do with the stdout? And if git was somehow replaced with something that only returned a status code and no output, then what are you going to do with no output? The important point is that errors can be thrown because errors can plausibly exist in a way that affects you. You should handle them, logging is fine as a bare minimum but you probably also want to return and exit out of the func in a way that communicates to the thing that called the func that "Something went wrong, and I don't have the results you're looking for".
- Spiritus 12y agoI agree. I should probably just add something like this at after every log: log.Println("ERROR", err) return out.Bytes(), err Or just: log.Println("ERROR", err) return []byte, err But I figured since the error will eventually get returned at the end anyway I moved on and kind of forgot about it.
- bkeroack 12y agoThere are usually two choices with non-nil errs: log.Printf("WARNING: something bad happened (nonfatal): %v\n", err) or: log.Fatalf("FATAL ERROR: %v\n", err) or maybe: // pass the buck return err That's it.