Adam Spiers <[EMAIL PROTECTED]> writes:
> All I've come up with so far is to change check_failures() to
> recognise with Error::Simple and treat it as a Test::Unit::Failure.
> But AFAICS T::U::Assertion::CodeRef is the only place which seems to
> consider a die() as a Test::Unit::Failure rather than a
> Test::Unit::Error, and I don't understand how this inconsistency can
> work, since a die from inside a T::U::Assertion::CodeRef will be
> indistinguishable from (say) a syntax error inside one.
Good point, which I'm afraid I didn't consider when I wrote
T::U::A::CodeRef.
> I only just figured out the die() -> Error::Simple ->
> Test::Unit::Error stuff yesterday, so I may be misunderstanding
> things, in which case, please let me know! If I'm right however,
> some possible solutions occur to me:
Nope, you're right about what's happening there. Sounds like I need to
comment that section a little better (or name the methods better).
>
> - Change T::U::Assertion::CodeRef::do_assertion to rethrow die()
> exceptions as Test::Unit::Failures. Almost ideal, except for the
> serious flaw that syntax errors in the coderef turn up as
> failures.
>
> - Change the semantics of T::U::Assertion::CodeRefs so that on
> failure they return($failure_msg) rather than die($failure_msg),
> and on success they return zero (a la shell)? That would be very
> easy to implement, although confusing in that it's the exact
> opposite of Perl's notions of true/false.
>
> - Change the semantics of T::U::Assertion::CodeRefs so that on
> failure they throw a Test::Unit::Failure rather than a die(). In
> that case, it would be better to drop the current requirement that
> a coderef has to return true to indicate success, since it would
> no longer be necessary.
>
> The third option is my preference.
Me too. And I can't for the life of me remember *why* I did it any
different.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
_______________________________________________
Perlunit-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/perlunit-devel
