search

cyberchitta / openai_ex

Community maintained Elixir library for OpenAI API
https://hexdocs.pm/openai_ex
Apache License 2.0
132 stars 18 forks source link

Improve non-interactive usage with more systematic error reporting / handling. #70

Closed restlessronin closed 3 months ago

restlessronin commented 10 months ago

Describe the feature or improvement you're requesting

Since the library has been designed for Livebook usage, it's primary use-case is interactive. If something doesn't work when a cell is evaluated, one can look at the returned json in the output and manually fix whatever is wrong with the request. The returned JSON is usually pretty clear about what went wrong.

This has worked well for my usage, but I'd like to support non-interactive usage for those who convert their livebook samples to libraries / apps that run non-interactively.

This might involve throwing / raising errors whenever the API returns an error message. Or returning an :error tuple (requiring a change at the point of call). My preference would be to mimic what the official python library does

Please upvote this if you this is something you need for your use case. Leave a comment if you have an opinion on how it should be handled.

restlessronin commented 3 months ago

Seems like there's cumulatively a lot of interest in this issue. Does anyone have opinions on whether this should be handled by raising exceptions or by return :ok and :error tuples? or perhaps both.

I have just released v0.7.0 that raises exceptions during streaming operations. In this case, raising exceptions seemed much cleaner than having the innermost loop of the stream operation handle an error tuple.

for non-streaming operations, it makes less of a difference, and perhaps the best option is to provide both mechanisms.

WDYT?

nwittstruck commented 3 months ago

Thank you for working on this! I'm currently deciding which openai package to use. Having proper error handling would be great! Just to add a data point - I prefer :ok and :error, especially in non-streaming contexts. Having both would of course also be fine.

restlessronin commented 3 months ago

@nwittstruck I want to clarify that it is already possible to handle errors, even though there is no :ok, :error tuple. The returned json already has enough status information for error handling.

This feature is more about systematizing the error reporting and handling (converting all errors into a single error taxonomy, based on the Openai python library), and raising exceptions (also to bring it in line with the python library).