Tag: ColdFusion

I just found out I get to go to cf.Objective this year. Woohoo.

Airline tickets, hotel room and conference reservation are already booked.

I was in a code review earlier last week, and someone said that they didn’t like using <cftry> and <cfcatch>. When we as a group investigated further it was revealed that they had used it “incorrectly,” experienced problems for doing so, and labeled the try catch model as bad, instead of the implementation. So I figured I would quickly go over my opinions of what you should be using them for.

To start with, the incorrect usage of <CFTry> was wrapping it around a troublesome page, so instead of visibly erroring, the page would just silently fail. To add insult to injury, there was an error in the cfcatch block which caused the whole thing to throw an application level error anyway. This was, to put it mildly, a flawed use of <cftry> and <cfcatch>.

In a nutshell, the <cftry> and <cfcatch> model in ColdFusion is for handling expected errors, as opposed to handling unexpected errors. ColdFusion has a pretty good system for handling unexpected errors – a combination of <cferror> tags, and use of onError in the application.cfc. So wrapping an entire page in <cftry> to catch any error that may come up is not only the wrong thing to do, it’s also pretty redundant.

In my opinion <cftry> and <cfcatch> should be used to handle errors around small pieces of code that have the potential to error in predictable ways. For example here is a line of code from one of my applications:

In it you’ll notice I’m doing a webservice call. In my experience webservices can have issues with the skeleton ColdFusion creates to consume them, especially if details about the webservice change. However, my application has little control over this webservice. So I wrap the call to the webservice in a <cftry> block, and if my expected error condition occurs, (something with to do the skeleton, or “stub objects”) I reset the webservice and try again.

You’ll notice that if it isn’t a “stub objects” problem, it assumes that it is some other issue, and rethrows the error so the application error handlers can tackle the problem. Why, because it is an unexpected problem, not an expected one.

In conclusion, I’m not speaking for all programming languages, but at least in ColdFusion <cftry> and <cfcatch> should be used to handle error that you can predict. The shouldn’t be your default error handling technique, and like a <Cflock> or a <cftransaction> they should surround as little code as possible.

This came up in a code review today. There were a couple misunderstandings about it, so I figured I would share the explanation publicly.

First, there are two types of whitespace what are in play here. Whitespace in your code for the purpose of properly formatting, and extra whitespace in your ultimate HTML output that comes from the various loops and other mysterious sources in ColdFusion. In simple terms, the first is good and the second is bad. However, you shouldn’t try and get rid of the first in order to get rid of the second.

First, to see a demonstration of what I am talking about, go to Wharton Computing’s Brainstorm. Once you’re there, “View Source” from your browser. At the top of the page, you’ll see a few lines of empty space before the DocType declaration. Select them with your cursor. You’ll see they’re not just page breaks, but spaces and tabs.

Now, go to the Wharton Wireless Troubleshooter (WWT). Do the same thing. You’ll notice a lot more whitespace at the top.

(I’m not picking on some random developer; I did both of these applications.)

That’s the easiest way to show you what I’m talking about. That whitespace makes the output HTML page bigger, as each piece of whitespace is a character that you are sending to you user.

Well how much of a problem is that little bit of whitespace? Well frankly not much, but if you understand how it gets created, you realize it can become a very big deal.

It gets created in loops that, in the case of the WWT, are being called before the header is rendered. (It can happen anywhere in a page, but that’s where it’s happening in this application.) So in the case of the WWT a few loops are generating say 1 character of whitespace per iteration. But suppose for a moment that you were doing hundreds or thousands of iterations… In multiple loops… with multiple characters per iteration… in multiple included files.

Like everything in coding, it’s not that one little thing is so bad, it’s that the little bad things tend to aggregate together, form large bad things, gain sentience and run amuck!

So what can you do to prevent whitespace? I could tell you. But Ray Camden does such a better job of it in his article about whitespace.

I would just add two things.

1. Ray mentioned a whole bunch of techniques you can use to reduce whitespace, but he doesn’t say what not to do to reduce it. (Awkward sentence, but bear with me.) You should not start formatting your source code to reduce the number of lines you use, the number of tabs, or the number of spaces. Readability of your code is still extremely important. Don’t change your code formatting to fix your html formatting. Find the spots that generate the whitespace. Then utilize the techniques he mentions to treat the problem topically. (My favorite method is to insert the <yo /> tag randomly throughout the source.)
2. If you’re not sure if you have this problem with your page, or if you’re not sure how big an impact the whitespace is having, use the tools at Web Site Optimization to see how big your output page is. Alternately this can be accessed via the Firefox Web Developer Toolbar.

I have found reason 531 to be glad I switched to developing in CFEclipse. Its name is Jupiter. It’s a code review tool for Eclipse. I find myself in complete disbelief, but I think I love a code review tool.

Why? What does do that makes me love it?

1. It links annotations directly to the code via line numbers.
2. Because of that linkage, you can open the code directly from the code comments.
3. It allows several levels of severity and categories of comments.
4. It allows for teams to collaborate on code reviews.
5. It saves notes in an easily parsed XML file for external reporting.

Dave and I are experimenting with it. It looks like it will make all of the code reviews we have to do a little easier.

I have to thank Kola Oyedeji who made some observations about a previous post of mine regarding code reviews.

I had a problem this week due to recent updates for DST. LDAP over SSL stopped working. It took me a fair amount of time to track down the answer, so I figured I would share.

Basically, the secure certificates store is tied to the JVM, not to ColdFusion or even JRUN. So when you update the JVM you lose a bunch of Certificate Authorities in your keystore (I assume since the file is so much smaller) and you lose any custom Certificate Authorities you may have added.

I found the solution at via a Google search at sagewire.org (JVM upgrade breaks secure CFLDAP connections), but basically the solution is to copy your former copy of the cacerts files to the new JVM’s location, then restart ColdFusion.

I don’t know if anyone checked out the new Scorpio wallpapers posted by Ben Forta, but in the lower right there is a line “<8 : 2007 >.” (See the blue wallpaper .)

I seem to remember reading this speculation somewhere else, but a quick Googling yielded nothing. I think that’s a pretty decent sign that Adobe is targeting August for ColdFusion 8. Woohoo. Good news to those of us that want to deploy apps for a new school year.

Either that or they’re screwing with us. If that is the case I say: “Shame on you, Tim Buntel. Shame.”