error handling: use user-error and rely on early abort control flow

[wbolster]

Use ‘user-error’ to signal errors, e.g. missing remotes, etc.

Unlike ‘message’, this causes an early return from the defun, so many
conditionals like ‘if’ and ‘cond’ are no longer needed.

Fixes #45.

[sshaw]

Hi, thanks for the pull request!

Wow almost 10 years since you opened the issue. Glad to see you're still here and using git-link! ❤️

Going back to the original issue (😅), I think the desire for user-error is symptom of the real issue: git-link is an interactive function, and people want to call it programmatically. Given this, wouldn't it better to extract the link generation into its own, "public", non-interactive function, that can signal via user-error, and the interactive version can handle it and continue to use message?

My thought process is mostly based on the premise that user-error is not for interactive functions, which may not be correct? It certainly can work in certain contexts but say if one has command-error-function configured, do you want that output into the minibuffer when calling this interactively?

Thoughts?

[sshaw]

Also in #45 you said:

i recently noticed that git-link doesn't report errors correctly

Do you just mean when calling it non-interactively or something else?

[wbolster]

the good news is that you're wrong 🙃:

user-error is fine for interactive commands; in fact it's how many built-ins signal a ‘problem’, such as previous-line while point is already on the first line of the file; see the docs on user-error

additionally, having a programmatic interface would be helpful indeed, b/c it would mean it can be called without accidentally opening a browser (depending on config etc), but that seems like a separate undertaking which can be done afterwards?