Idiom for partial failures
Richard Damon
Richard at Damon-Family.org
Thu Feb 20 21:14:45 EST 2020
On 2/20/20 12:30 PM, David Wihl wrote:
>
> (first post)
>
> I'm working on the Python client library [0]for the Google Ads API [1]. In some cases, we can start a request with a partial failure [2] flag = True. This means that the request may contain say 1000 operations. If any of the operations fail, the request will return with a success status without an exception. Then the developer has to iterate through the list of operation return statuses to determine which specific ones failed (example [3]).
>
> I believe that it would be more idiomatic in Python (and other languages like Ruby) to throw an exception when one of these partial errors occur. That way there would be the same control flow if a major or minor error occurred.
>
> The team is asking me for other examples or justification of this being idiomatic of Python. Can you recommend any examples or related best practices?
>
> [0] https://github.com/googleads/google-ads-python
>
> [1] https://developers.google.com/google-ads/api/docs/start
>
> [2] https://developers.google.com/google-ads/api/docs/best-practices/partial-failures
>
> [3] https://github.com/googleads/google-ads-python/blob/master/examples/error_handling/handle_partial_failure.py
>
> Thanks!
> -David
My first thought is that partial failure also means partial success,
which means that it shouldn't throw.
One key thing about exceptions is that they provide an easy way to ABORT
a current operation on an error and trap to an error handler. They allow
you to begin the operation starting a try block, have a number of
operations that don't need to worry about all the little error
conditions that would force you to abort the operation, and then handle
all the errors at the end, and the code in the middle doesn't need to
propagate the error codes, as the exception carries that information. If
you throw on a partial failure/partial success, then you really need to
IMMEDIATELY catch the error so you can continue the successes, at which
point returning an error value is normally clearer.
Now, an alternative would be rather than throwing an exception, would be
to effectively raise a signal and call an error callback with the
details of the failed operation, and let the call back handle (or
record) the error information, so the caller doesn't need to go through
all the successes to see if there was an error.
Now, if the code was going to iterate through the success anyway, then
there isn't as much of a cost to detect the errors that occured.
--
Richard Damon
More information about the Python-list
mailing list