On Tuesday 30 January 2007 19:19, A. Pagaltzis wrote: > * 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.
I'm happy to see this is generating some comments, which is exactely what i wanted. Hopefully this will help Test::Exception author to make his module better, lighter or simply help me and other users understand Test::Exception better. If dies_ok is not removed (and I actually don't care because I've made the mistakes enough to learn to avoid it) the warning and maybe placing dies_ok later in the documentation will, IMO, help new comers. Cheers, Nadim.
