in reply to Named Subroutine Parameters: Compile-time errors vs. Run-time warnings

Thanx to Google-Books here the complete passage (underlining added)

Requiring the named arguments to be specified inside a hash ensures that any mismatch, such as:

$line = padded({text=>$line, cols=>20..21, centered=>l, filler=>$SPACE});

will be reported (usually at compile time) in the caller's context:

Odd number of elements in anonymous hash at demo.pl line 42

Passing those arguments as raw pairs:

$line = padded(text=>$line, cols=>20..21, centered=>l, filler=>$SPACE);

would cause the exception to be thrown at run time, and from the line inside the subroutine where the odd number of arguments were unpacked and assigned to a hash:

Odd number of elements in hash assignment at Text/Manip.pm line 1876

The only difference in error handling that I can think of might result from unquoted keys ... (?)

Cheers Rolf

  • Comment on Re: Named Subroutine Parameters: Compile-time errors vs. Run-time warnings

Replies are listed 'Best First'.
Re^2: Named Subroutine Parameters: Compile-time errors vs. Run-time warnings
by AnomalousMonk (Archbishop) on May 26, 2009 at 18:29 UTC
    The only difference in error handling that I can think of might result from unquoted keys ...
    I don't understand this point. Can you give an example?
      Sorry please forget it.

      It was just a guess that the fat comma => might act differently in curlies than in a parameter list, resulting in another (or missing) quoting behavior of barewords at the LHS.

      But this wouldn't make sense...

        You're right: fat comma acts the same regardless of curly or non-curly context.