Michael Goldish wrote:
- What if we're interested in the status for some reason? Its value
may indicate what went wrong with the child process.
Put it in the exception string.
But I want its value to be examined programmatically in the code.
It's less comfortable to retrieve it from a string.
Then create a custom exception object and put it in a field.
- If we throw an exception we should add a parameter that controls
whether an exception should be thrown (something like
"ignore_status")
because in some cases we don't want to throw an exception.
I'll complain every time I see it. If you don't care if the command
succeeds or not, why run it in the first place?
I care, but sometimes I don't want to fail the test when a command fails.
I can put every run_bg() call in a try-except statement, but that misses the
point of raising exceptions in the first place.
I think it's very rare to want to let the test continue even if some
command fails.
Can you give examples?
exception such as "something failed after migration"?
Chained exceptions can provide detailed information.
Wouldn't it complicate the test code?
How can I provide a detailed message such as "test command failed after migration" --
can you illustrate this in a small example?
try:
code
code
code
except e:
raise ChainedException('exception while running migration test', e)
Instead of checking each code line, you provide a wrapper for the entire
test.
But if status != 0, will there actually be a pid to kill?
If the timeout expires and the process is still running, status is
None.
functions which can return with three possible outcomes are difficult
to use.
I tend to see it as two possible outcomes: completion or timeout. In the former
case, status is returned. In the latter, None is returned.
The caller has to test for three possible outcomes. Success, failure,
and 'command is running in the background'. If your callsites don't
check for all three, something's wrong.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
