* 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
> throws_ok just isn't enough.
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 $@ itself;
handy because $@ is maddeningly difficult to correctly preserve
for testing.
> 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?
Yeah, `dies_ok` should stay. But it should have a fat warning in
the documentation, because it *is* easy to unwittingly misuse.
--
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1}
&Just->another->Perl->hack;
#Aristotle
