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
