I must admit that I'm a little surprised myself, but it turns out that or's precedence is so low that it is actually lower than return (probably because return is treated as a list operator). Which leads to the following result:

perl -MO=Deparse -e "sub test { return int(rand(2)) or print 'Nope' }"
sub test {
    print 'Nope' unless return int rand 2;
}
-e syntax OK
[download]

Two ways to do what you want (beyond the one you already proposed), either with a temp variable:

my $result;
$result = something() or croak "Something went wrong";
return $result;
[download]

sub mySub
{
  ...
  something() or croak "Times are a'croaking";
}
[download]

When you're trying to suss out precedence problems the "-p" flag to B::Deparse can be useful to get it to shove in explicit parens everywhere.

$ perl -MO=Deparse,-p -e "sub test { return int(rand(2)) or print 'Nop
+e' }"
sub test {
    ((return int(rand(2))) or print('Nope'));
}
-e syntax OK
[download]

The cake is a lie.
The cake is a lie.
The cake is a lie.

There's a third way: Parens can be used to override precedence.

return (
   something()
      or croak "Times are a'croaking"
);
[download]

A return is evaluated in the context of the sub's caller.

so this variant

my $result;
$result = something() or croak "Something went wrong";
return $result;
[download]

is safer (resp. only correct) if it's supposed to be a scalar.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}

How can return fail? Perl's warning is spot-on. If you want to croak when the return value isn't true, that needs to be associated with the sub call, not the return call. Precedence takes care of that, and you can still use or if you add parens:

$ perl -Mstrict -wE'sub foo{} sub bar{return foo() or die "died"} bar(
+)'

Possible precedence issue with control flow operator at -e line 1.
[download]

$ perl -Mstrict -wE'sub foo{} sub bar{return foo() || die "died"} bar(
+)'

died at -e line 1.
[download]

$ perl -Mstrict -wE'sub foo{} sub bar{return (foo() or die "died")} ba
+r()'

died at -e line 1.
[download]

Hope this helps (but you already got it I reckon...)!

In the first case consider what is happening:

(return something()) or (croak "Something didn't work.\n");
[download]

return will always return. Interestingly, it may return a false value (return 0; or return undef or return ''; or even return ()). But it will certainly return. Once it has returned, the subroutine is done. There's no way to ever reach the low precedence 'or'. It's like hanging up the phone before you ever hear the other party ask a question.

In the second example, it's like this:

return (something() || croak "Something didn't work.");
[download]

Now something() is evaluated, and if it is false, then the || evaluates the righthand side, which is the croak call. Croak throws an exception and consequently control is never handed to the return.

Before return can run, its arguments must be evaluated. In the first example its argument is something()'s return value. In the second example, the expression is the entire construct including the || croak.

When in trouble with perlop precedence always use parentheses.

The 1. variant

> return something() or croak "something didn't work";

equals

(
   ( return something() ) 
   or 
   ( croak "something didn't work" )
);
[download]

But doesn't make much sense, because the or-branch is never reached.

A "normal" return almost never fails, and if return fails, the program dies right away:

> perl
return
__END__
Can't return outside a subroutine at - line 2.
[download]

(update: one might argue that the former shouldn't even compile, but there are probably use-cases in combination with do FILE )

The 2. variant

> return something() || croak "something didn't work";

equals

 
return ( 
    ( something() ) 
    or 
    ( croak "something didn't work" )
);
[download]

which looks a bit strange but is somehow possible.

still Carp::croak() means to die

    # die of errors (from perspective of caller)
    croak "We're outta here!";
[download]

so returning the value of croak doesn't really make sense either.

update

The latter means mixing two very different control flows in one line ... irk.

In the spirit of PBP : "make control flows immediately clear!", mixing two is quite confusing for the reader.