use Perl

• It's not the subroutine, it's the block. (Score:1)

  by Abigail (26) on 2006.10.30 4:27 (#51353) Journal

  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.

  Reply to This

  • Re: (Score:2)

    by Matts (1087)

    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: (Score:2)

    by Dom2 (2981)

    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