Performance of chained methods.
David Dick
david_dick at iprimus.com.au
Wed Oct 30 00:54:24 CST 2002
Scott Penrose wrote:
>
> On Wednesday, Oct 30, 2002, at 16:38 Australia/Melbourne, Daniel
> Walmsley wrote:
>
>> As soon as one procedure returns undef, the subsequent call will
>> fail, and
>> the failure will chain back down without reaching out to the end. I
>> think.
>
>
> Yes I know, that is why my three methods cater for that each time.
>
>> That is:
>> Example 1:
>> 1) FirstMethod works
>> 2) AnotherMethod fails, returns undef
>> 3) Perl barfs when asked to call MoreMethods
>> 4) You return undef
>>
>> Example 2:
>> 1) FirstMethod fails
>> 2) Perl barfs when asked to call AnotherMethod
>> 3) You return undef
>>
>> Therefore I don't see it as being any less efficient than any other way,
>> UNLESS Perl is automatically breaking it into separate statements with
>> separate return values without treating it like one big "block" that
>> can die
>> at any step and return.
>>
>> Whoops, I guess I just failed to answer your question. Bugger it,
>> I'll hit
>> send anyway.
>>
>> As to whether it's "bad practise", I guess it depends on whether
>> anyone who
>> cares about that sort of thing is ever going to look at your code
>> again ;)
>
>
> The eval{} method works perfectly, and in theory eval {} has almost no
> performance hit, however I FEEL like I am doing a VERY bad think ;-) i
> don't like bad hacks.
>
> Scott
why a bad thing? after all, catching exceptions is a feature of most
modern languages. although i got tripped up with them badly the other
day. Forgot to send a rollback to the db after catching an unrelated
exception.... bugger.... :)
More information about the Melbourne-pm
mailing list