mnako
API design: return a zero value silently or an explicit error?
While using letters to archive email, I cut myself on a sharp edge that I wasn't expecting. This may have been my fault, but I wanted to ask about it.
In some cases, ParseDateHeader can return a zero value time. Looking at the code, I think that this is a deliberate choice. I wonder, however, if you have considered returning an error instead—as net/mail does when it fails to parse a date. If ParseDateHeader can return a zero value, then all return values must be tested with IsZero before they can be (safely) used. It seems more idiomatic to me to return (time.Time, error) instead.
No matter what you decide, I would suggest documenting the functions that can return zero values clearly. Maybe I should have realized that the most likely way for a parsing function never to return an error is if it (sometimes) returns a zero value, but I didn't. I'd like to save other people from the same surprise.
In any case, thanks for letters and thanks for thinking about this topic.
I agree with you, I think it has been an oversight to return a zero value instead of returning an error.
Let me tackle the date formats in https://github.com/mnako/letters/issues/160 and https://github.com/mnako/letters/pull/164 and then change the signature of ParseDateHeader().
This will be a breaking change but I do believe that it should be done that way.
