My vote is yes. Originally UserCacheDir returned a string but an empty string could lead to bugs that are hard to track down. I'm happy to send a CL if that's what we'd like to do.

I think an error makes its use kinda tedious.

I'd prefer to just return "/" if the env is unset and let things fail with a permission error later.

But I don't object if everybody else prefers an error.

One benefit of not returning an error: that allows for flag definitions to easily default to a location relative to $HOME:

var configPath = flag.String("config",
  filepath.Join(os.UserHomeDir(), ".config", "i3"),
  "path to write configuration file to")

Of course, the above expression is not portable and should probably be replaced by os.UserConfigDir, which should respect $XDG_CONFIG_DIR on Linux? :)

Aside from that, I agree with @bradfitz in that $HOME is so rarely unset that not caring much about that case is an okay trade-off, and users who work in such strange environments will easily be able to make the connection between the error and the lack of a $HOME variable.

What about returning "$HOME is unset"? That way, the error message would be “plumbed through”.

What about returning "$HOME is unset"? That way, the error message would be “plumbed through”.

At that point we should just return an error in my opinion.

That said, I don't know enough about the circumstances of when $HOME would not be set (and whether this is a valid error condition). My vote was for API consistency going forward.

If it returns a descriptive error message that will probably make its way back to the user who can then say "Oh, this program isn't working because $HOME isn't set—I can investigate why that is happening and fix this".

Looking at the code, on windows, it's not as simple as returning the empty string on failure since it concatenates two environment variables so one could be set while the other not. It could check and return "" if either are "", without returning an error. But as the logic increases so does the usefulness of a clear error message explaining what went wrong where.

Discussed with @bradfitz and @andybons. The missing error was mainly for convenience but hopefully the work on error handling will address that instead of losing the ability in the API to tell whether it succeeded.

Change https://golang.org/cl/150418 mentions this issue: os: return an error from UserHomeDir to match UserCacheDir