From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH][KVM_AUTOTEST] Added functionality to the preprocessor to run scripts Date: Wed, 03 Jun 2009 11:13:37 +0300 Message-ID: <4A2630B1.80403@redhat.com> References: <1580897273.1063661244013718354.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, David Huff To: Michael Goldish Return-path: Received: from mx2.redhat.com ([66.187.237.31]:46992 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754968AbZFCINi (ORCPT ); Wed, 3 Jun 2009 04:13:38 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n538Dfwm013218 for ; Wed, 3 Jun 2009 04:13:41 -0400 In-Reply-To: <1580897273.1063661244013718354.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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.