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