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';
>
> If the SIG{__DIE__} dance happens entirely in T::E (as I suggested in
> my patch) then the user's tests do not require any change. I thought
> it'd be good to test all three things: that eval returned something
> other than undef, that $@ is empty, and SIG{__DIE__} wasn't called.

The thing is that, at the moment, the various T::E subs all try quite
hard to pretend to be eval. I see this as a good thing since it's a
good match to the exception tracking code people will write in the
rest of their application. Adding the {__DIE__} dance moves away from
that which makes me nervous for reasons I've not entirely worked out.

I think that this is just being eval. T::E is using eval internally
and in it's own use just has to go an extra mile to notice this class
of previously ignored errors. That same bug occurs in user code as
well so I suppose what this means is that fully safe user code should
also be doing this exact same thing.m

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 errors that were previously being
ignored that the user really ought to be fixing up their code because
that's buggy as well.

At this point I end up thinking it would be nice if there were another
module out there that got all the error checking done correctly so
T::E could use its implementation and so could user code.

Josh

Reply via email to