* Nadim Khemir <[EMAIL PROTECTED]> [2007-02-02 16:30]:
> I don't even know how we could handle the exception out of
> DESTROY blocks but maybe this is already an error. I wish it
> would propagate and we could handle it.
I wish! http://www.perlmonks.org/?node_id=594416
--
*AUTOLOAD=*_;sub _{s/(
* David Golden <[EMAIL PROTECTED]> [2007-02-02 13:35]:
> There is a different case that needs to be considered. Module
> Fribble uses an eval in it's DESTROY method without error and
> thus Foo's fatal error in an eval vanishes.
I think there we can all agree at this point that global
variables a
On Friday 02 February 2007 10:09, Adrian Howard wrote:
> [snip]
> I'm unconvinced that this should be the default behaviour because I'm
> fairly certain that a number of these new test failures - possibly
> the majority - won't actually be indications of code that doesn't work.
>
> For example. Mod
Hi Dave,
On 2 Feb 2007, at 12:30, David Golden wrote:
[snip]
There is a different case that needs to be considered. Module Fribble
uses an eval in it's DESTROY method without error and thus Foo's fatal
error in an eval vanishes.
[snip]
Good point.
Because Perl normally warns but doesn't die
On 2/2/07, Adrian Howard <[EMAIL PROTECTED]> wrote:
For example. Module Foo uses objects from module Bar, which uses
objects from module Ni, which uses objects from module Fribble, which
has a exception in a DESTROY block that the author deliberately
doesn't catch because it doesn't signify an er
On 1 Feb 2007, at 21:56, Nadim Khemir wrote:
On Thursday 01 February 2007 22:37, Joshua ben Jore wrote:
I'd be a happy guy if a paranoid T::E caused consternation and people
to post "OMG! My stuff fails now!" to perlmonks or whatever.
I use T::E extensively and I, too, would like to see a c
On 1 Feb 2007, at 21:37, Joshua ben Jore wrote:
[snip]
Ok, I'll give you that a user may want to ignore errors that occur
during scope cleanup but from the point of view of T::E, it seems
relatively clear that an error really has occurred.
I'd tend to think
that T::E's default behavior would be
On Thursday 01 February 2007 13:37, Joshua ben Jore wrote:
> I'd be a happy guy if a paranoid T::E caused consternation and people
> to post "OMG! My stuff fails now!" to perlmonks or whatever.
Be very careful with that. I fixed a bug in Test::MockObject a while back and
a few people yelled ver
On Thursday 01 February 2007 22:37, Joshua ben Jore wrote:
> I'd be a happy guy if a paranoid T::E caused consternation and people
> to post "OMG! My stuff fails now!" to perlmonks or whatever.
I use T::E extensively and I, too, would like to see a complete paranoid
module.
Someone wrote, "don'
On 2/1/07, Adrian Howard <[EMAIL PROTECTED]> wrote:
On 1 Feb 2007, at 16:28, Joshua ben Jore wrote:
[snip]
> There's is nothing special about what T::E is doing to detect errors -
> it just turns out the popular practice of looking at $@ is flawed.
> That's a problem with the pattern and I expect
On 1 Feb 2007, at 16:28, Joshua ben Jore wrote:
[snip]
There's is nothing special about what T::E is doing to detect errors -
it just turns out the popular practice of looking at $@ is flawed.
That's a problem with the pattern and I expect that what it means is
that if T::E starts detecting error
On 2/1/07, Adrian Howard <[EMAIL PROTECTED]> wrote:
On 31 Jan 2007, at 16:42, Joshua ben Jore wrote:
[snip]
>>dies_ok { $o->annoying_corner_case } 'exception thrown';
>>
>> do the SIG{__DIE__} dance make the tester write
>>
>>dies_ok { $o->annoying_corner_case; 1 } 'exception thrown';
>
On 31 Jan 2007, at 16:42, Joshua ben Jore wrote:
[snip]
dies_ok { $o->annoying_corner_case } 'exception thrown';
do the SIG{__DIE__} dance make the tester write
dies_ok { $o->annoying_corner_case; 1 } 'exception thrown';
If the SIG{__DIE__} dance happens entirely in T::E (as I suggeste
On 1/31/07, Adrian Howard <[EMAIL PROTECTED]> wrote:
On 30 Jan 2007, at 20:11, Joshua ben Jore wrote:
> Interestingly, this has caused me to wonder how well Test::Exception
> handles the corner cases where $@ is clobbered during the scope ending
> of eval{} and related.
It doesn't. It's been o
On 1/31/07, Joshua ben Jore <[EMAIL PROTECTED]> wrote:
Here's some pathologies that are possible and why I want to delegate
this job to a module (this is also why you don't want to do this stuff
by hand. Use a module):
If the eval ended with no errors but there was a die() during its
scope clean
On 30 Jan 2007, at 20:11, Joshua ben Jore wrote:
Interestingly, this has caused me to wonder how well Test::Exception
handles the corner cases where $@ is clobbered during the scope ending
of eval{} and related.
It doesn't. It's been on my list for some time, but I'm too lazy :-)
I've just
Hi Nadim,
On 30 Jan 2007, at 17:17, Nadim Khemir wrote:
[snip]
The bad guys:
# Check that something died
dies_ok { $foo->method1 } 'expecting to die';
Am I the only one who got this to pass, to find out later that what
cause the
error had nothing to do with the message I displayed.
[sn
On 30 Jan 2007, at 19:48, Eric Wilhelm wrote:
# from Nadim Khemir
# on Tuesday 30 January 2007 09:17 am:
# all Test::Exceptions subroutines are guaranteed to preserve the
state # of $@ so you can do things like this after throws_ok and
dies_ok like $@, 'what the stringified exception should
On 30 Jan 2007, at 18:19, A. Pagaltzis wrote:
That could easily be accomodated by having `throws_ok` accept a
sub ref as its condition argument. Then Test::Exception could
pass the value of $@ to this sub as the first argument, and clear
$@ to force people to use that argument instead of $@ its
On Tuesday 30 January 2007 22:17, Joshua ben Jore wrote:
> Then you can't use ref() because that return all kinds of wrong values.
Someone ought to put that on temporary tattoos and hand them out at every YAPC
for the next five years.
-- c
On 1/30/07, David Golden <[EMAIL PROTECTED]> wrote:
On 1/30/07, Joshua ben Jore <[EMAIL PROTECTED]> wrote:
> Interestingly, this has caused me to wonder how well Test::Exception
> handles the corner cases where $@ is clobbered during the scope ending
> of eval{} and related. I've just filed a bug
On 1/30/07, Joshua ben Jore <[EMAIL PROTECTED]> wrote:
Interestingly, this has caused me to wonder how well Test::Exception
handles the corner cases where $@ is clobbered during the scope ending
of eval{} and related. I've just filed a bug against it at
http://rt.cpan.org/Ticket/Display.html?id=2
Nadim Khemir wrote:
> The bad guys:
>
> # Check that something died
> dies_ok { $foo->method1 } 'expecting to die';
>
> Am I the only one who got this to pass, to find out later that what cause the
> error had nothing to do with the message I displayed. Checking that something
> dies is _no
On Tuesday 30 January 2007 12:18, Nadim Khemir wrote:
> Any of the subroutines could croak. So my point is "is there any point in
> using lives_and" at certain places when it's not used in thousands of other
> places?
Sure -- when calling code that you know throws exceptions under certain
circum
On 1/30/07, Nadim Khemir <[EMAIL PROTECTED]> wrote:
I believe the example in Test::Exception is not as good as it could be.
# Check that something did not die
lives_ok { $foo->method2 } 'expecting to live';
Doesn't explain much about when to use it.
You'd use (lives|dies|throws)_ok when
On Tuesday 30 January 2007 19:09, A. Pagaltzis wrote:
> * Nadim Khemir <[EMAIL PROTECTED]> [2007-01-30 18:20]:
> > # Check that a test runs without an exception
> > lives_and { is $foo->method, 42 } 'method is 42';
> > Isn't this equivalent to is($foo->method, 42 , 'method is 42')?
> > The test
On 1/30/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
* Pete Krawczyk <[EMAIL PROTECTED]> [2007-01-30 19:00]:
> How about code that dies with an object? dies_ok lets you
> inspect the object in $@, whereas throws_ok only lets you see
> if it's part of a class. What if you want to see if $@ meets
>
Subject: Re: Bad test functions in Test::Exception
From: Nadim Khemir <[EMAIL PROTECTED]>
Date: Tue, 30 Jan 2007 20:48:55 +0100
}> And finally, what if I truly don't care why something dies, just that it
}> did? Why should I be penalized for writing *any* test?
}
}And how wou
# from Nadim Khemir
# on Tuesday 30 January 2007 09:17 am:
> # all Test::Exceptions subroutines are guaranteed to preserve the
> state # of $@ so you can do things like this after throws_ok and
> dies_ok like $@, 'what the stringified exception should look like';
>
>This wouldn't be needed if die
On Tuesday 30 January 2007 18:53, Pete Krawczyk wrote:
> snip
> No, you're not - but shunning all possible uses of dies_ok becasue you
> didn't write a test as complete as you could have isn't the fault of
> Test::Exception.
> How about code that dies with an object? dies_ok lets you inspect the
On Tuesday 30 January 2007 19:19, A. Pagaltzis wrote:
> * Pete Krawczyk <[EMAIL PROTECTED]> [2007-01-30 19:00]:
> > How about code that dies with an object? dies_ok lets you
> > inspect the object in $@, whereas throws_ok only lets you see
> > if it's part of a class. What if you want to see if $@
* Pete Krawczyk <[EMAIL PROTECTED]> [2007-01-30 19:00]:
> How about code that dies with an object? dies_ok lets you
> inspect the object in $@, whereas throws_ok only lets you see
> if it's part of a class. What if you want to see if $@ meets
> multiple criteria? There's plenty of valid cases where
* Nadim Khemir <[EMAIL PROTECTED]> [2007-01-30 18:20]:
> # Check that a test runs without an exception
> lives_and { is $foo->method, 42 } 'method is 42';
> Isn't this equivalent to is($foo->method, 42 , 'method is 42')?
> The test framework will catch the error if any. It's just
> weird to att
Subject: Bad test functions in Test::Exception
From: Nadim Khemir <[EMAIL PROTECTED]>
Date: Tue, 30 Jan 2007 18:17:38 +0100
}I like Test::Exception, it's a very fundamental test module with
}Text::NoWarning, Test::Deep and other goodies. Still, I believe some of the
}functions mad
I like Test::Exception, it's a very fundamental test module with
Text::NoWarning, Test::Deep and other goodies. Still, I believe some of the
functions made available should not be there at all.
The good guys :
# Check that the stringified exception matches given regex
throws_ok { $foo->me
35 matches
Mail list logo
