The point is that I am accustomed to using cftry/cfcatch around potential
problematic code; so wrapping the entire index with cftry rose a flag for me
as to what the downsides might be? Right now it is a necessary evil, but 4.1
will hopefully rectify the issue.
I am not even going to comment on the importance of
planning/design/architecture because that is a 'gimme' and I always take
performance into consideration while planning, that's a good thing.
Mike
> <rant>
> I have no idea if wrapping the entire request in a
> CFTRY..CFCATCH will slow down the request. In fact, I don't
> even care, unless app performace becomes a problem, and I've
> spent time optimizing the rest of the system (particularly
> the DB). IMHO, you should NEVER make high-level architecture
> decisions based on performace. Design the system as well as
> possible from an architecture standpoint. Experience shows
> that good architecture usually leads to good performance, and
> the places that it doesn't are usually because the need for
> maintainability or abstraction were more important than raw
> speed. Six months down the road, it's a lot easier to do
> optimization than rearchitecting, so put them in the right
> order on the priorities list up front.
> </rant>
>
> In FB4's case, if you've got a exception handling plugin,
> you're entire parse file is wrapped in a CFTRY..CFCATCH
> anyway, so adding one to index.cfm isn't going to matter
> much. The only different will be the runtime core, which is
> quite trivial (the vast majority of the core code is in the
> other three files).
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
