Comments for DaveShuck.com

Comment on ColdFusion 9 catch() is not thread-safe! by Nathan D

Nathan D — Wed, 14 Dec 2011 21:01:32 +0000

Hmm, guess it stripped out instead of escaping the tags. The code snippet should be:

try{
1/0;
}
catch(any foo){
variables.exceptionCalledFoo = foo;
}

Comment on ColdFusion 9 catch() is not thread-safe! by Nathan D

Nathan D — Wed, 14 Dec 2011 20:43:50 +0000

In my quick test I was not able to have the "foo" variable generated by catch(any foo) actually overwrite an existing variables.foo in the same instance of the CFC - if your finding holds true, shouldn't it? For instance, in this code if you run makeVariable, then dump, then run generateException on the same instance and then dump getVariablesScope again the original variables.foo is still there: try{ 1/0; } catch(any foo){ variables.exceptionCalledFoo = foo; }

Comment on Naked Domains in Google App Engine with GoDaddy by daain

daain — Tue, 08 Nov 2011 16:42:51 +0000

Thanks a lot, really nice writeup

The screenshots made it super easy too!

Comment on CFML wishlist: All collections should extend Iterator by Kurt Wiersma

Kurt Wiersma — Sat, 05 Nov 2011 23:29:09 +0000

I would love to see this as well especially with the Grails syntax!

Comment on CFML wishlist: All collections should extend Iterator by Steve Good

Steve Good — Fri, 04 Nov 2011 20:32:37 +0000

Argh, it killed my markup. Here’s a link to my gist: https://gist.github.com/1340409

Comment on CFML wishlist: All collections should extend Iterator by Steve Good

Steve Good — Fri, 04 Nov 2011 20:30:40 +0000

I’d be even more excited to see something like the Grails GSP implementation of each. Something like:

Comment on ColdFusion 9 catch() is not thread-safe! by Peter Boughton

Peter Boughton — Fri, 04 Nov 2011 15:11:37 +0000

Dave, Railo also has the option to not require var scoping (named “local scope mode” in Admin>Settings>Scope page) – if you set this to “always” then it should behave the same as OpenBD (i.e. always place new variables in functions in the local scope instead of variables scope.)

Comment on ColdFusion 9 catch() is not thread-safe! by Gert Franz

Gert Franz — Fri, 04 Nov 2011 15:08:18 +0000

There is a setting in the Railo admin which exists for a while already that you can have Railo put the variables into the local scope by default and not always. In this way you can make use of both behaviors, depending on which you need in which context. And using local.e is a perfectly valid syntax. You wouldn’t have to write variables.e if you need it there in the other case…

Gert

Comment on ColdFusion 9 catch() is not thread-safe! by Adam Presley (@adampresley)

Adam Presley (@adampresley) — Thu, 03 Nov 2011 14:08:13 +0000

That is crazy nuts. First, why not allow you to define where that catch variable goes? Secondly, just about every other language in the world defaults to a local variable scope for *ANY* variable defined in a method (notice I said *just about every*, and not *all*), so why can’t CF? And of course there is no semephore mechanism to control access to volatile variables…

Lesson here? High traffic sites, shouldn’t use best practices of exception handling for fear of race conditions.

Comment on ColdFusion 9 catch() is not thread-safe! by dshuck

dshuck — Thu, 03 Nov 2011 14:00:06 +0000

Alan, thank you very much for responding and pointing out the problem with my first test. I have modded the first test so that it is consistent with the others. What it shows is that OpenBD is the only engine that treats it as I would hope! I have modded the last edit to say: “EDIT (again): I have tested this in both Railo and OpenBD. OpenBD, due to the fact that it puts variables within methods in the var scope by default does not fail on the first test. Railo, does fail. However by using the variables scope like ColdFusion. However, it allows you to do catch( any local.e ) and var scope e ahead. So in a nutshell, ColdFusion is the only engine that does not give us any way to do thread-safe error handling.”