On 05/28/2012 03:04 AM, tangchen wrote: > hi~ > > On 05/28/2012 02:38 PM, Alex Jia wrote: >> On 05/25/2012 09:52 PM, Chris Evich wrote: >>> On 05/25/2012 06:26 AM, Alex Jia wrote: >>>> IMHO, we should reuse virsh_dumpxml() then give a optional >>>> 'to_file' parameter rather than defining many similar function, >>>> for example, >>>> >>>> def virsh_dumpxml(name, to_file="", uri="") if to_file: cmd = >>>> "dumpxml %s> %s" % (name, to_file) else: cmd = "dumpxml %s" % >>>> name >>>> >>>> return virsh_cmd(cmd, uri) >>> >>> I like this idea. >>> >>>> >>>> And then I saw each virsh cmd need to deal with exception >>>> case, we should do it in virsh_cmd() to simplify codes. >>> >>> I don't quite understand your meaning here, could you explain >>> further? >>> >> virsh_cmd() is a common function and will run all of virsh cmds by >> utils.run() then it just returns stdout now, a caller will do >> result check and catch a error further, if we can put these work in >> virsh_cmd(), I think it will simplify our codes. >> > I thought about this before. > > The problem here is that users cannot judge if the virsh command runs > correctly through stdout returned by virsh_cmd(). So we make > virsh_cmd() raise an exception when the command is wrong. > > My idea was catching and handling exception in virsh_cmd(), and > making virsh_cmd() return two values: command's exit status and > stdout. In this way, users don't need to handle exceptions, and they > are able to know the command is wrong with exit status. > > But if we do so, wherever virsh_cmd() is called should be modified. > It will be a large number of work. I am still thinking about it. > There may be something coincident with your idea. :) >
Yes, changing the behavior too much will break a lot of stuff (I did it before :) What about adding an optional keyword parameter like 'extended_return=False'? When set 'True' make it return cmd_result instance. Or, if we want to shell users away from dealing with cmd_result, return a tuple instead, like '(stdout,stderr,exitcode)'. I think this could be a good compromise. -- Chris Evich, RHCA, RHCE, RHCDS, RHCSS Quality Assurance Engineer e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214 _______________________________________________ Autotest mailing list Autotest@test.kernel.org http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
