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
--
https://mail.python.org/mailman/listinfo/python-list
