* 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