in reply to Re^8: Error handling in chained method calls
in thread Error handling in chained method calls

A method call in Moose is the same as a method call in a vanilla Perl

Wouldn't the normal response to such a requirement be to use the before or after or around keywords to add pre and/or post conditions to the methods?

And wouldn't those extra layers have some performance penalty?

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP an inspiration; A true Folk's Guy
  • Comment on Re^9: Error handling in chained method calls

Replies are listed 'Best First'.
Re^10: Error handling in chained method calls
by stvn (Monsignor) on Oct 25, 2010 at 18:09 UTC
    Wouldn't the normal response to such a requirement be to use the before or after or around keywords to add pre and/or post conditions to the methods?

    Actually, probably not where I would go with this no. It would get way to messy to have all this advice sprinkled about your various roles and classes. Not every Moose solution, as you often seem to imply, involves sprinkling more sugar and performance penalties on top of the code.

    I would actually have to agree with your original post, if the chained method calls fail it is likely for one of two reasons. First, the objects are designed poorly and aren't returning the right values/throwing the right error conditions. Second, there is a valid error condition and the chaining really should stop.

    I honestly have a hard time thinking of a case where failing in the middle and not throwing an exception of some kind would be useful. The intended body of work would be existing incompletely and that really should be an error.

    And wouldn't those extra layers have some performance penalty?

    Sure, executing code always incurs a performance penalty, you of all people should know that ;)

    -stvn
[reply]
      Actually, probably not where I would go with this no.

      Fair enough.

      Sure, executing code always incurs a performance penalty, you of all people should know that ;)

      Indeed. Hence not adding my (bad) Moose solution to the benchmark.

      I've long since accepted that Moose is not targeted at the vast majority of the stuff I do. That its performance is the Perlish trade-off for its facilities.

      I truly wasn't trolling. I'd still like a Moose-compatible solution that: a) avoided as many extra function calls (wrappers) as possible (perhaps even source-filtered to in-line pre & post conditions, type-checks and accessors; b) ditched most of the reflection stuff that I personally see little use for. But I know that goes against the very grain of Moose.

      Maybe I'll get around to finishing pudu one day :)

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom