golang driving me nuts these days. enjoying the performance, but time.Parse put me into a ragequit mode last night and I really wish it was possible to return a thing OR nil
func ParsedTimeOrNil(s string) *time.Time {
t1, err := time.Parse(time.RFC3339, s)
if err != nil {
return nil
}
return &t1
}That said, I hate this, all the ways it's opinionated and praised zealously for it as the best thing since sliced bread.
If time.Parse is failing, you either have bad input or a bug, right? If you are ok with this failing without even logging the error, something might be wrong with the design.
You can't build your own programming language inside of Go. If you absolutely cannot mentally handle functions returning an error and you having to type "if err != nil { fix the problem }", you really need to find a different programming language. But, errors happen all the time, and handling them correctly is the difference between an unreliable piece of garbage that randomly fails and software you and your users can trust. There is, unfortunately, no automation around making software reliable.
(BTW, stack trace proponents... stack traces don't capture loop iterator variables, or "why" you're calling a particular function. But when you write a quick error message with fmt.Errorf, you can include all of those things.)
Software engineering is a job of continuous improvement. Make it really easy to find the right place to target improvements!
A language where you need to constantly write wrappers around everything just to get basic functionality is quite a miserable language, imho. That's like C…
Which makes complete sense, since Go was designed as Google's C for Dummies.