On Tuesday, Oct 15, 2002, at 17:26 US/Pacific, S. Isaac
Dealey wrote:
Isaac the Butcher of Fusion ... :)
Careful, that might stick! :)
At least then I'd be assured a reputation. :)
[horrific factorial implemented with try/catch snipped]
Of course not... For starters, there are existing
Mike
Thanks for the reply, can I confirm that this is only relevant to CFMX
And that with CF5 there is no performance hit involved in heavy use of
try catch blocks?
Thanks
-Original Message-
From: Mike Chambers [mailto:[EMAIL PROTECTED]]
Sent: 15 October 2002 15:31
To: CF-Talk
You can certainly try. :) The testing I did was on CF 5 and it seemed to
produce a similar result. I'd actually be really interrested to see time
results that indicate a situation in which a try-catch block is less
expensive than any equivalent non-try-catch codeblock.
Mike
Thanks for the
On Wednesday, Oct 16, 2002, at 06:13 US/Pacific, S. Isaac Dealey wrote:
[horrific factorial implemented with try/catch snipped]
Yech... I pitty your server. :P
My Mac laptop, you mean? :)
In answer to Kola's question about try-catch in CF5: try-catch
generally introduces an overhead in every
Hi
Sean, have I missed something, are you saying try and catch add a
significant performance overhead?
Thanks
Kola
-Original Message-
From: Sean A Corfield [mailto:[EMAIL PROTECTED]]
Sent: 15 October 2002 02:08
To: CF-Talk
Subject: Re: switch-case was RE: BlueDragon (was RE: How
On Monday, Oct 14, 2002, at 17:13 US/Pacific, S. Isaac
Dealey wrote:
There is another way to simulate variables or ranges in a
case statement with a cftry and cfcatch blocks...
try/catch is a pretty heavy operation - you should only
use it for (unexpected) error cases, not normal
damn keyboard shortcuts...
I've used try catch for a number of non-error handling
items .. properly implemented, it works pretty well. Or at
least it has for me.
Have you timed it? (I won't even start on the stylistic
implications of this!)
I guess I probably should explicitely time test
The try isn't too expensive, but the catch can be. However, running a
bunch of trys within a loop can also degrade performance.
The catch generates significant overhead when an exception is thrown
because a copy of the stack has to be created.
a quick search of google turns up:
Thanks Mesh,
I suppose I should clarify by saying that I haven't simply disregarded the
original intent of cftry all-together. I do use it mostly for error
handling, although much of it is for custom error handling, such as server
side form validation. In most cases I use it no more than once on
On Tuesday, Oct 15, 2002, at 07:51 US/Pacific, S. Isaac Dealey wrote:
I suppose I should clarify by saying that I haven't simply disregarded
the
original intent of cftry all-together. I do use it mostly for error
handling, although much of it is for custom error handling, such as
server
There have been a handful ( maybe a half dozen )
situations where I found
the cftry was extremely helpful in creating an easily
human read/writeable
codeblock where the only alternative I could think of
would have been a horrible mess of spaghetti code.
Yes, that is true. There are
On Tuesday, Oct 15, 2002, at 17:26 US/Pacific, S. Isaac Dealey wrote:
Isaac the Butcher of Fusion ... :)
Careful, that might stick! :)
[horrific factorial implemented with try/catch snipped]
Of course not... For starters, there are existing UDF's on cflib.org to
handle factorials. :P And I'm
I should probably keep my nose out of this one. :)
Ah... this is why competition is good.
I don't have a new feature, per se, but I do have a pet
peeve that came about from porting an app written in
another language to an online CF version.
The CFCASE portion of CFSWITCH is sorely limited
No, the ZIPs aren't common usage, but I've certainly had to deal with it a lot. Just
used them to illustrate the point. Another issue with the same application was doing
age ranges. Simple to type ''30 to 45'' and annoying to have to type out
''30,31,32,33...'' etc.
What I'm curious about
Since we are on a wish list, I would rather just have the ability to use
variables in a case statement. Then you could do a hack like
cfscript
myrange=;
for(i=30; i lt 45; i=i+1){
devnull = listAppend(myrange,i,,);l
}
/cfscript
cfswitch expression=#myswitch#
cfcase
This kind of functionality would basically make null and void what Jochem
had mentioned about SWITCH statements being faster than a series of
IF-ELSEs. He had suggested that SWITCH could be faster because only a
single expression needs to be evaluated whereas with the IFs, multiple
expressions
No, the ZIPs aren't common usage, but I've certainly had
to deal with it a lot. Just used them to illustrate the
point. Another issue with the same application was doing
age ranges. Simple to type ''30 to 45'' and annoying to
have to type out ''30,31,32,33...'' etc.
Yea, I'd probably
Since we are on a wish list, I would rather just have the
ability to use variables in a case statement. Then you
could do a hack like
cfscript
myrange=;
for(i=30; i lt 45; i=i+1){
devnull = listAppend(myrange,i,,);l
}
/cfscript
cfswitch expression=#myswitch#
cfcase
Yeah, that is a good point. The times I would like to use it the most are
more like in situations where
cfset SOMESTATE=1
cfest ANOTHERSTATE=2
cfswitch expression=#blarg#
cfcase value=#SOMESTATE# ...
/cfswitch
-Original Message-
From: S. Isaac Dealey [mailto:[EMAIL
On Monday, Oct 14, 2002, at 17:13 US/Pacific, S. Isaac Dealey wrote:
There is another way to simulate variables or ranges in a case
statement
with a cftry and cfcatch blocks...
try/catch is a pretty heavy operation - you should only use it for
(unexpected) error cases, not normal
20 matches
Mail list logo
