|P is for Practical|
Re^10: Error handling in chained method callsby stvn (Monsignor)
|on Oct 25, 2010 at 18:09 UTC||Need Help??|
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 ;)