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 to be as careful as possible and
only less so if the user asks for it. I think it'd be great if a
user's tests break because T::E changed. That'd mean there's something
they were probably overlooking. They're forced to react to it. That's
good, isn't it? Just because modules use T::E without error *today*
doesn't mean they should pass tomorrow if and when bugs in T::E are
discovered.
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. 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 error in the code and
they know that exceptions don't propagate out of DESTROY blocks.
Are you really saying you want the authors Foo, Bar and Ni to start
getting test failures because of a "mistake" in Fribble? Especially
since it's a "mistake" that has zero affect on the functionality of
Foo, Bar, Ni or Fribble?
Now if somebody wanted to write a Perl::Critic plugin that checked
for uncaught exceptions in DESTROY blocks I'd be all for that. Making
working code fail its test is, however, not my idea of a good time.
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 really, really would not. Breaking CPAN installs of modules that
work isn't my idea of a good time. I've already had that happen to me
twice with Test::Exception.
People shout and me and I cry :-(
Cheers,
Adrian
