On 01/03/2011 09:26 PM, Eduardo Habkost wrote:
> On Mon, Jan 03, 2011 at 08:34:07PM +0200, Michael Goldish wrote:
>> +# Exception context information:
>> +# ------------------------------
>> +# Every function can have some context string associated with it.
>> +# The context string can be changed by calling context(str) and cleared by
>> +# calling context() with no parameters.
>> +# get_context() joins the current context strings of all functions in the
>> +# provided traceback. The result is a brief description of what the test was
>> +# doing in the provided traceback (which should be the traceback of a caught
>> +# exception).
>
> I am sure people will eventually forget to call context() to clear
> previous context calls, and people won't notice until an actual error is
> raised on another section.
>
> What about a decorator like:
>
> @context("hello")
> def a()
> ...
>
> That would set/clear the context automatically when the function is
> called/returns?
- In most cases it isn't necessary. The context dict maps whole stack
traces to context strings, which means that if a function is called
twice from different places in the code, it won't have the same context
string. The only problematic case is functions that are called in loops
and declare context strings. I suppose those should be rare, and all
they need to do to prevent the problem is call error.context() at the top.
- A function can (and should) change its context string at runtime (for
example: before reboot, after reboot). If each function could only
declare a single context, we could just use the function's name and we
wouldn't need a context.
>> +#
>> +# For example: assume a() calls b() and b() calls c().
>> +#
>> +# def a():
>> +# error.context("hello")
>> +# b()
>> +# error.context("world")
>> +# get_context() ----> 'world'
>> +#
>> +# def b():
>> +# error.context("foo")
>> +# c()
>> +#
>> +# def c():
>> +# error.context("bar")
>> +# get_context() ----> 'hello --> foo --> bar'
>
> Above sample code is a good candidate to be in a doctest string or unit
> test, isn't it?
>
Probably, but I've never used those before so I'll have to find out how
it's done.
--
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
