Idiom for partial failures

[Richard Damon]

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