All the Perl that's Practical to Extract and Report

The case of the stupid API

Matts on 2006-10-29T02:24:54

AKA - Annoyed by default return

Perl sometimes annoys me.

A couple of weeks ago it was the fact that a my variable declared in a if (...) block is still valid in the same block's elsif (...) section, meaning that you get warnings if you do:

if (my $val = $tiedhash{$key}) {
  ...
}
elsif (my $val = $othertiedhash{$key}) {
  ...
}
This vexxed me greatly.

Today I was bugged by a combination of my own bad API and perl's decision to make the last value in a sub be the return value,

Frankly if I don't specifically return anything, I would rather any return value be ignored. Or I wish there were a "use strict 'return'" which would turn off this ugly behaviour.

My API was a network socket API, which if I returned a value from "sub process_line" it would send that back as a response. I forgot about the return value and instead wrote my own response to the socket.

But by the magic of perl's default return value, I got my $self->{status} value written to the socket.

Thank god for tcpdump. It truly saved the day by seeing what exactly I was writing to the socket, and reminded me about my dumb API.

Perl::Critic

ChrisDolan on 2006-10-29T04:16:08

Perl::Critic can help here. There is a plugin called Perl::Critic::Policy::Subroutines:RequireFinalReturn that checks your code and ensures that every subroutine ends with an explicit return (or die, goto, croak or exit).

But I like it

Aristotle on 2006-10-29T04:43:57

I get a lot of milage out of implicit return – I write many functions that consist of a single expression (disregarding parameter parsing), which read much nicer that way.

Maybe precisely because I use it so purposefully, I am always keenly aware that subs always return something, and so when writing subs that aren’t supposed to, I usually put a bare return in there.

Re:But I like it

Matts on 2006-10-29T14:15:36

I do this too, as can be seen in my code on CPAN. I just would like a strict mode to turn it off.

Default behavior

sigzero on 2006-10-29T12:44:10

Aren't those Perl rules? I know that last statement is the return by default is covered in "Learning Perl", so I guess I always have that in my head. The IF statement doesn't bother me as I look at those as blocks.

Re:Default behavior

Matts on 2006-10-29T14:14:34

As I said, it was partly due to the dumb API, but often times the last statement is hidden somewhere in an if block, or while block or something. I think I'd personally rather have an explicit return, via use strict 'return';

Re:Default behavior

sigzero on 2006-11-03T02:53:31

I think I'd personally rather have an explicit return, via use strict 'return';

I get what you are saying now.

It's not the subroutine, it's the block.

Abigail on 2006-10-30T09:27:37

It's the fact that return value of blocks is the last expression evaluated. And the body of a subroutine is a block.

The fact that blocks return the last expression evaluated is what makes writing concise maps and greps.

Also note that whether a subroutine returns something or not is not determined by a return, or a last expression. Like anything else, it's determined by context. A subroutine will return nothing, if, and only if, it's called in void context. Otherwise, it will return something, even if it's an empty list (in list context), or the undefined value (in scalar context).

Having said all this, I fail to understand why you can be bitten by Perl returning something from an subroutine without it having an explicit return statement. It sounds to me that you have assigned the return value of a subroutine to a variable - and you have done that with a subroutine you expected to return "nothing". Surely the mistake lies there - and not in the fact the sub returned something after all.

Re:It's not the subroutine, it's the block.

Matts on 2006-10-30T13:51:40

It's an OO API, so you subclass process_line to process a line of data. But I forgot that (somewhere in another file/class) that if process_line returns a scalar it gets sent to the client. It's hard to see that sort of thing in OO virtual APIs sometimes, but as everyone has rightly pointed out - it was programmer error.

Doesn't mean I think "use strict 'return'" is any less of a good idea though.

Re:It's not the subroutine, it's the block.

Dom2 on 2006-10-30T20:57:25

I've been bitten by this in mod_perl handlers. I forgot to return OK, and the final statement was returning undef. That triggered a "Use of uninitialised value" message in the error log... but it had no line number info. That took me months to track down. I've always been very explicit about using return since then.

-Dom