On 21/02/20 10:05 AM, Stefan Ram wrote:
David Wihl <davidw...@gmail.com> writes:
I believe that it would be more idiomatic in Python (and other languages lik=
e Ruby) to throw an exception when one of these partial errors occur.
I wonder whether the term "idiomatic" is too heavily
burdened here.
Python offers an idiom for handling a failure to do an
operation - the exception.
But you have special case of a run-time program of many
operations, and you want the execution of the program to
continue even in the case of failures to execute some of
the operations. I am not aware of Python offering an idiom
for this special case.
I am always thinking about terminology first. So I'd say:
You need to /define/ what "success" and "failure" means in
the case of your operation. Then return normally in the case
of success and return by exception in the case of failure.
Not arguing - and if I were the logical answer is "not Python", but...
PyTest (runs unit-tests, enables TDD) offers options to stop the
test-runner at the first error-found or to keep going for up to
n-errors. We can test for an error condition and if experienced such
will not 'count' or stop the test-run. It distinguishes between
hard-errors and warnings, and enables us to choose to 'elevate' one to
the level of the other, and vice-versa. Its run-report lists which tests
worked and which didn't (the 'last' or the up-to "n") - a clear advance
on the OP's experience.
I think someone has already discussed, but if the intent is
bulk-processing ("batch processing") then I'd expect to find a means of
'bailing-out' when an error is found, or of back-tracking to locate errors.
Perhaps, like my good-looks, my expectations of a professional standard
are higher-than-average?
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
