Fwd: New checker "jc.IsNil"

[Tim Penhey]

On 19/11/14 01:16, roger peppe wrote:
> On 18 November 2014 04:22, Tim Penhey <tim.penhey at canonical.com> wrote:
>> 'ello 'ackers,
>>
>> This is something that I have been meaning to add for quite some time.
>>
>> We have been recording stack traces with the juju/errors library, but
>> until now, they have been of limited use.
>>
>> One of the key places I have wanted to see the stack trace for a while
>> is when running tests, and I have a function that returns an error, I'd
>> normally have:
>>
>>   c.Assert(err, gc.IsNil)
>>
>> to make sure the error is nil.  Now I have added a checker into the
>> juju/testing/checkers that is error aware.
>>
>> If you now use jc.IsNil instead of gc.IsNil, and the value is an error,
>> and the error has a stack trace, it will get printed out.
>>
>> Very handy.
>>
>> The dependencies of master have the versions you need to use it now.
>>
>> Cheers,
>> Tim
> 
> One thing that I've been meaning to do for a while is
> change all occurrences of c.Assert(err, gc.IsNil) to
> c.Assert(err, gc.Equals, nil), because technically the former is
> wrong, as it could be a typed nil but still erroneously
> pass the test.

Interesting.  I've modified my checker to reject typed nils, and am
currently running it over the entire codebase. A few intermittent
failures the first time through, and a place I missed. Currently running
the second time through.


> One possible alternative to your jc.IsNil that you may want to consider
> is something I did in errgo - you can implement the GoString
> method to produce the error trace. Then you'll automatically
> see the error trace whatever gocheck checker you use, because
> gocheck prints the error with %#v, which will invoke GoString.
> I've found it very helpful.

I did see that in errgo, but I made he explicit decision not to do that
with the errors package.

Tim