Re^10: Error handling in chained method calls

[stvn]

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 ;)

[BrowserUk]

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 :)