in reply to Re^6: Modern Perl Programming Highs and Lows
in thread Modern Perl Programming Highs and Lows

Is it just me, or is this almost another CPAN one-liner? 
  use Test::Simple 'no_plan';
  sub throws_ok(&@) {
    my ($test, $qr, $msg) = @_;
    eval { shift->() };
    ok($@ =~ /$qr/, $msg);
  }
  throws_ok { die "blah" } qr/bla/, 'blah blah';

[download]

Replies are listed 'Best First'.
Re^8: Modern Perl Programming Highs and Lows
by chromatic (Archbishop) on Apr 30, 2009 at 18:12 UTC

    Your implementation provides no diagnostics on failure; that code accounts for much of the rest of Test::Exception's complexity.

[reply]
Re^8: Modern Perl Programming Highs and Lows
by diotalevi (Canon) on May 10, 2009 at 16:36 UTC

    Well... you neglected to account for DESTROY { eval {} } and DESTROY { die } for any objects created in your test code. You failed to account for buggy overloading in exception objects. To do all of that correctly you've got to use the return value of the eval{} to decide failure, hook and unhook $SIG{__DIE__}, save $@ so when you stringify it, you don't accidentally cause it to clobber itself.

    Perl exception handling is actually a garden of pain.

    ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

[reply]
[d/l]
[select]
      Those things you mention fall into the "doctor, it hurts when I do this" category. Normal code shouldn't need DESTROY at all, and if it does, it should be extremely careful. And if you're creating complex overloaded exception objects, you have already lost. What does your test module's overloaded $SIG{__DIE__} do with a module that itself overloads $SIG{__DIE__}?

      Sure, it's possible to build ever-more-complicated exception mechanisms with lots of corner cases, and to require more testing modules to control them. Sometimes you may even be forced into this silliness. But since you're inviting a world of hurt by doing so, you should ask yourself first whether a simpler solution could work.

[reply]

        No, none of this is "it hurts doctor" stuff. It's quite normal to have exception objects. It's normal for exception objects to have stringification. It's unusual but not not bad to have a destructor. It is bad to fail to protect your caller against $@ clobbering but mistakes can happen. It's pretty unusual to see your tests $SIG{__DIE__} get overridden and it's worth automating the instrumentation of that happening. Mostly, I really like Test::Exception because with perl, you must be paranoid and this lets me outsource my paranoia.

        ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

[reply]

In Section Meditations