get '/foo/bar' => sub {
  # 30 lines of sub here
}

# more code here
[download]

The reason is that a named sub can end with just a curly bracket (and no semicolon), but the line from the callback needs to be finished with a semicolon. When I forget it, I get synatx errors somewhere below in the following code.

The same happens with eval BLOCK.

But the weirdest errors are not perl errors, but something that can happen in every programming language: accidentally running a different copy of the code than what you just modified. Either because it's in a different directory (or, even harder to find) because you're in an ssh session on one xterm, and on the local computer with another xterm. Since I have near-identical copies of my home directories on multiple machines, that can be a real pain to find out.

A module had the line return 1 outside of a sub.

It's pretty normal for a module to have return 1 outside of a sub. Are you sure that's the cause of the problem you saw?

At least as near as I can possibly see. It wouldn't be the first time I thought A was the issue when in fact B was. But I'm fairly certain. I narrowed it down by the old comment out code until nothing is left but the bare minimum to recreate the bug. The sample is pretty slim.

There are in fact two possible ways to make the bug go away. (a) add a printf within the sub that wants to use the $SOME_CLASS or (b) comment out the return 1. Plain old 1; ( no return) at the end of the file works fine. It is only when the word return is added. I'm not inclined to blame the bug on failing to have a printf in the sub since that doesn't seem to me to be a reasonable requirement of proper use of package my variables.

Here is the code that shows the problem. The test script:

use strict;
use warnings;
use Monks::Foo::ReturnInModule;
weAreOffToSeeTheWizard();
[download]

The module Monks/Foo/ReturnInModule.pm:

Read more... (1295 Bytes)

I can't replicate the issue with v5.10.x and v5.12.2 (while I can with an old 5.8.4). So, maybe it was a bug that's been fixed in the meantime... (?)

...but wasn't able to find a similar thread.

Somewhat related: "Can't happen" bugs

The cause? a stray comma: print $fh, $sData instead of print $fh $sData.

My latest wierd bug: calling rmdir created a file, even as it removed a directory.

Not really of course. What actually happened is that a symbolic link that once counted as a directory got reclassified as a non-directory when its target (a directory) got deleted.

I had constructed a list of files I wanted to delete. The list contained only directory "A" and its sibling non-directories. When I reran the query that generated the original deletion list instead of finding no files, two unexpected files "L" and "L1" suddenly appeared.

It just so happened that "L" and "L1" were linked through a long chain of links to "A". As long as "A" existed they were classified as directories and did not appear on my generated list of things to delete. As soon as "A' was deleted, these links lost their directory classification and showed up as "non-directories" on my list of things to delete. No files created, just a simple reclassification.

Beware mixing File::Find, file type checks, symbolic links, and file/dir removal.

while (1) {
  # use a block for structuring things
  {
     print "do something, then leave the loop\n";
     last;
  }
}
[download]

while (1) {
  # use a block for structuring things (a bit unconventionally)
  if (1) {
     print "do something, then leave the loop\n";
     last;
  }
}
[download]