Re: Testing error handling that calls "die"

my $errmsg = eval(SubCall($silly));

There are two use cases of eval: eval BLOCK catches exceptions, and eval EXPR takes a string as the source of a Perl program, and executes it.

You've accidentally used the latter, but you should be using the former. If you write eval(SubCall($silly)), the call to SubCall is not influenced by the eval at all, but rather the return value of the SubCall will be used as a string to be interpreted as Perl code.

The correct solution is to just use the BLOCK form of eval:

my $success = eval { SubCall($silly); 1 };
ok !$success && $@ eq $errmsg, 'died with the right error message';
[download]

In Perl 6, the eval BLOCK form has been renamed to try, so there's less potential for confusion. It also works as a statement prefix without any block, so you could write

my $success = try SubCall($silly);
ok $!.defined && $! eq $errmsg, 'died with the right error message';
[download]

Perl 6 - second systems done right

Comment on Re: Testing error handling that calls "die" Select or Download Code

Replies are listed 'Best First'.
Re^2: Testing error handling that calls "die" by davies (Monsignor) on Dec 27, 2011 at 10:44 UTC
I get it now. I didn't know about the two forms of `eval`, and that was why I couldn't get my original code or toolic's explanation to work. I will admit that I struggled for a while despite your explanation, as `$success` did not behave as I expected. I was not mentally prepared for it to return `undef` on an error and spent quite a while trying to work out what had gone wrong. Trying to debug a non-existent bug is not recommended. :-) One other thing surprised me slightly. Every use of `ok` I had seen previously uses brackets, but I notice that your examples do not. I have put brackets in for consistency, but is this just cargo cult? If not, what is the effect of using the brackets? Regards, John Davies	[reply] [d/l] [select]
Re^3: Testing error handling that calls "die" by moritz (Cardinal) on Dec 27, 2011 at 11:11 UTC
One other thing surprised me slightly. Every use of ok I had seen previously uses brackets, but I notice that your examples do not. I have put brackets in for consistency, but is this just cargo cult? If not, what is the effect of using the brackets? The parenthesis after a subroutine name are another peculiarity of Perl 5 :-) When perl enounters an identifier like `ok` in the source code, it can interpret it in two ways: either as a "barword" (a string literal), or as the name of a subroutine. If perl knows about a subroutine of that name, it decides in favor of the subroutine interpretation, otherwise it chooses the bareword. If you put parenthesis after the identifier, it always chooses the subroutine. So, the parens are only needed if the subroutine is declared later in the file. Since you `use Test::More;` (or something similar) at the start of your test file, all the testing routines are immediately imported, and thus known as subroutines. Here are a few examples of the parsing differences: $ perl -le 'print STDOUT foo' # bareword foo $ perl -le 'use strict; print STDOUT foo' # strict disables barewords Bareword "foo" not allowed while "strict subs" in use at -e line 1. Execution of -e aborted due to compilation errors. $ perl -e 'use strict; sub foo { }; foo' # works fine $ perl -e 'use strict; foo; sub foo { };' # error, foo is a bareword, +because it's not declared yet Bareword "foo" not allowed while "strict subs" in use at -e line 1. Execution of -e aborted due to compilation errors. $ perl -e 'use strict; foo(); sub foo { };' # that's where you actuall +y need the parens; no error [download] Perl 6 - second systems done right	[reply] [d/l] [select]