in reply to "warn" is your best friend

As the other contributors have already said, warn can be your best friend with some caveats, when print STDERR ... becomes a better friend - especially in my case, where I have a habit of attempting to use warn whilst trying to debug a failing test case ... entirely forgetting that the test cases use (pun intended:-) Test::Warnings which 'eat up' all warnings and pass/fail accordingly, thus providing, IMO, a more than reasonable demonstration of Heisenbergs' Uncertainty Principle :-D

A user level that continues to overstate my experience :-))

Replies are listed 'Best First'.
Re^2: "warn" is your best friend
by tobyink (Canon) on Mar 23, 2014 at 14:39 UTC

    You want to know my trick for that? When debugging, instead of outputting with warn $message, output messages with ::diag $message.

    Advantages:

    • ::diag outputs messages prefixed with a "#" sign, so it looks nice in test output.

    • ::diag won't cause Test::Warnings fails.

    • When you're not running your test suite, Test::More probably won't be loaded, so the ::diag function won't exist. This will cause ::diag $message to bomb loudly, so you won't forget any debugging messages you've scattered amongst your code.

      Note that because of the way function calls are parsed in Perl, including parentheses in the function call like ::diag($message) will make it bomb at run-time instead of compile-time. This is why I recommend not using the parentheses in ::diag $message. If you need to resolve ambiguities using parentheses, you can always do so with external ones like (::diag $message).

    • Along the same lines, a statement that starts with :: looks weird, so will stand out like a sore thumb when you're looking for it to remove it.

    use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name
[reply]
[d/l]
[select]
      Hiya tobyink,

      Much as tho' I like and indeed really appreciate, your insight into debugging the test cases, I was actually referring to the use of spurious debugging statement(s) in the code itself - where my use of warn suggested that the code was even more broken than and in a different place to, the actual problem.

      A user level that continues to overstate my experience :-))
[reply]

        Yes, I meant use ::diag for debugging in the module code itself; not just in the test suite!

        use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name
[reply]
[d/l]

In Section Meditations