Make error logging configurable

[joecorkerton]

Currently if there is an error with my LLM call, Langchain generates a Logger.error message

langchain/lib/chains/llm_chain.ex

Line 951 in 16e8956

Logger.error("Error during chat call. Reason: #{inspect(reason)}")

As a consumer of this package, I should have the choice about what logging I want to be done in the case of different errors. The error level logs here should be removable so I have the option to decide how to configure my logs

[brainlid]

Hi @joecorkerton! Do you propose then, that the library not emit any Logger.error messages? But it would return an :error tuple and you, as the consumer of the library would choose to log or not?

[joecorkerton]

Do you propose then, that the library not emit any Logger.error messages? But it would return an :error tuple and you, as the consumer of the library would choose to log or not?

Yeah as far as I'm aware that's how most Elixir libraries work, they wouldn't generate error logs themselves and instead return error states (or throw an error) for the user of the library to handle themselves (I don't think I've seen any other Elixir library that includes error Logger calls before).

But also pragmatically I understand that this behaviour already exists in the library and some users might be relying on it. So some sort of configuration that lets you opt out of these errors logs would be nice (or even the ability to have an error thrown rather than a Logger.error would be good as we can rescue that and then do our own thing where with a Logger.error we can't avoid it being processed as far as I'm aware).

[brainlid]

@joecorkerton I thought more about it and I agree with you. In the LLMChain module, my intention is to remove the Logger.error lines. There aren't many of them. I'd rather not add configuration complexity that attempts to not alter the behavior at all and instead opt for a CHANGELOG notice of the behavior change.

I don't expect the removal of the lines to present any significant issue for users.

I'd welcome a PR for this change but I plan to get to it later if no PR is made. Thanks!

[joecorkerton]

@brainlid I've attempted to create a PR in line with what was discussed, let me know if it's what you had in mind