llms: extract common llms errors to shared declaration

[wgeorgecook]

PR Checklist

• Read the Contributing documentation.
• Read the Code of conduct documentation.
• Name your Pull Request title clearly, concisely, and prefixed with the name of the primarily affected package you changed according to Good commit messages (such as memory: add interfaces for X, Y or util: add whizzbang helpers).
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. Fixes #123).
• Describes the source of new concepts.
• References existing implementations as appropriate.
• Contains test coverage for new functions.
• Passes all golangci-lint checks.

This addresses the comment Travis made in this PR I previously made. It specifically extracts the ErrorIncompleteEmbedding error and the ErrorEmptyResponse error used in the files in the /llms directory.

I specifically targeted these errors because they're the ones I encountered using LangChain Go, there is still more work to be done in consolidating all of the other potentially shared errors.

[wgeorgecook]

Looks like the ci lint wasn't run before these files made it into main. I'm working on fixing them all now.

[wgeorgecook]

CI is now passing.

[wgeorgecook]

@tmc I resolved conflicts with main for this and ensured that the linter is happy in the /llms directory. Let me know if you want to take this in a different direction but I think this is a good start towards centralizing these error messages.

[tmc]

Thanks so much, this ia great to see.

[tmc]

"thrown" isn't exactly the right language in Go,

[wgeorgecook]

@tmc Fair. I'll change it to "is returned"

[tmc]

I wonder if llms is the right place to put the errors, I don't love the new source dependency on what is already a pretty large package implies. I don't have a better suggestion. @eliben do you have an opinion here?

[wgeorgecook]

@tmc I have the same concern. It feels weird to have a root level errors package since the exported types are directly related to the LLMs. But it doesn't have to be. But it would probably also feel weird to have a root level errors package with just any and all exported errors in it. Very open to suggestions.

[eliben]

I wonder if llms is the right place to put the errors, I don't love the new source dependency on what is already a pretty large package implies. I don't have a better suggestion. @eliben do you have an opinion here?

I don't see the advantage of this approach - what's the motivation here? How are llm-unique errors going to be represented?