All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Michael Goldish <mgoldish@redhat.com>
Cc: autotest@test.kernel.org, kvm@vger.kernel.org,
	Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [KVM-AUTOTEST PATCH v2 3/6] [RFC] Introduce exception context strings
Date: Wed, 05 Jan 2011 18:21:35 +0200	[thread overview]
Message-ID: <4D249A8F.8090009@redhat.com> (raw)
In-Reply-To: <4D249855.30607@redhat.com>

On 01/05/2011 06:12 PM, Avi Kivity wrote:
> On 01/05/2011 05:45 PM, Michael Goldish wrote:
>> In complex tests (KVM) an exception string is often not informative 
>> enough and
>> the traceback and source code have to be examined in order to figure 
>> out what
>> caused the exception.  Context strings are a way for tests to provide
>> information about what they're doing, so that when an exception is 
>> raised, this
>> information will be embedded in the exception string.  The result is 
>> a concise
>> yet highly informative exception string, which should make it very 
>> easy to
>> figure out where/when the exception was raised.
>>
>> A typical example for a test where this may be useful is KVM's reboot 
>> test.
>> Some exceptions can be raised either before or after the VM is 
>> rebooted (e.g.
>> logging into the guest can fail) and whether they are raised before 
>> or after
>> is critical to the understanding of the failure.  Normally the 
>> traceback would
>> have to be examined, but the proposed method makes it easy to know 
>> where the
>> exception is raised without doing so.  To achieve this, the reboot 
>> test should
>> place calls to error.context() as follows:
>>
>> error.context("before reboot")
>> <carry out pre-reboot actions>
>> error.context("sending reboot command")
>> <send the reboot command>
>> error.context("after reboot")
>> <carry out post-reboot actions>
>>
>> If login fails in the pre-reboot section, the resulting exception 
>> string can
>> can have something like "context: before reboot" embedded in it.  
>> (The actual
>> embedding is done in the next patch in the series.)
>
> It would be nice to make the error context a stack, and to use the 
> with statement to manage the stack:
>
>
>    with error.context("main test"):
>        foo()
>        with error.context("before reboot"):
>            bar()
>
> If foo() throws an exception, the context would be "main test", while 
> if bar() throws an exception, the context would be "before reboot" in 
> "main test".
>

btw, you can have a decorator for enclosing an entire function in an 
error context:

    @function_error_context('migration test')
    def migration_test(...):
        ...

anything in migration_test() is enclosed in that context.  But we're 
just repeating the ordinary stack trace with something more readable.

-- 
error compiling committee.c: too many arguments to function


  parent reply	other threads:[~2011-01-05 16:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-05 15:45 [KVM-AUTOTEST PATCH v2 1/6] [RFC] Fix Unhandled* exceptions Michael Goldish
2011-01-05 15:45 ` [KVM-AUTOTEST PATCH v2 2/6] [RFC] CmdError: remove extra blank line between methods Michael Goldish
2011-01-05 15:45 ` [KVM-AUTOTEST PATCH v2 3/6] [RFC] Introduce exception context strings Michael Goldish
2011-01-05 15:54   ` Eduardo Habkost
2011-01-05 16:12   ` Avi Kivity
2011-01-05 16:21     ` Eduardo Habkost
2011-01-05 16:22       ` Avi Kivity
2011-01-05 18:55       ` Michael Goldish
2011-01-05 19:10         ` Eduardo Habkost
2011-01-05 16:21     ` Avi Kivity [this message]
2011-01-05 16:36       ` Eduardo Habkost
2011-01-05 16:39         ` Avi Kivity
2011-01-06 11:56       ` Michael Goldish
2011-01-05 15:45 ` [KVM-AUTOTEST PATCH v2 4/6] [RFC] Embed context information in exception strings Michael Goldish
2011-01-05 15:45 ` [KVM-AUTOTEST PATCH v2 5/6] [RFC] KVM test: use error.context() in migration_with_file_transfer Michael Goldish
2011-01-05 15:45 ` [KVM-AUTOTEST PATCH v2 6/6] [RFC] KVM test: use error.context() in kvm_preprocessing.py Michael Goldish

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D249A8F.8090009@redhat.com \
    --to=avi@redhat.com \
    --cc=autotest@test.kernel.org \
    --cc=ehabkost@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mgoldish@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.