Only on first request: "null pointers are another name for undefined values"

[JocularGargoyle]

We recently updated from CF7 to CF8 and have started getting the following error:

===========
The system has attempted to use an undefined value, which usually indicates a programming error, either in your code or some system code.

Null Pointers are another name for undefined values.
===========

However, it doesn't occur every time you load the page. In fact, it only occurs the first time you load the page. If you hit refresh, it's fine. If you hit refresh again, it's still fine. Visit it a little bit later, still fine. Visit it a day later? The error might be back.

We're using MySQL and not doing anything weird with the queries. For example:

<cfquery name="qGetJobs" datasource="#APPLICATION.dsn#">
SELECT * FROM jobs ORDER BY dateposted DESC

</cfquery>

(Incidentally, dateposted is a timestamp and not empty in any record.)

I've searched the forums here and found several people receiving the same error, but they're not magically fixing themselves on refresh. I did find a post on an other site that solved the problem by recreating the CF DSN.

Do you have any idea why this might be happening? Thanks!

[ilssac]

My first guess based on the tiny bit of code you shown, is that "Application.dsn" is not defiend when the query is first run, but afterwords it gets defined and then works until such a time is it expires.

But there could be other causes of this error that exist somewhere else in the application.

[JocularGargoyle]

We'd actually considered that, but even if I replace APPLICATION.dsn with the actual datasource name the problem persists. Thanks for offering that up though!

[ilssac]

Well what part of the code is the error actually pointing to and what does the code at that point do?

98.73% of time NULL pointer is just an awkward way to say 'undefined variable'.

[-__cfSearching__-]

My guess would have been the application variable, but you may want to check some of the suggestions in the links and comments here:

http://www.coldfusionjedi.com/index.cfm/2007/9/28/ColdFusion-8-MySQL-HostMySite-and-NPEs

[JocularGargoyle]

That's exactly the kind of information I was looking for, cfsearching... thank you!

[JocularGargoyle]

For example:

<cfoutput query="qGetJobs">

<p><strong>#jobName#</strong><br />

#client#<br />

#dueDate#<br />

#notes#</p>

</cfoutput>

"Notes" will sometimes be empty, but it's defined. If it were a problem with an undefined variable, wouldn't it continue to throw the error no matter how many times the page had been refreshed, or back when we were running CF7?

[JR__Bob__Dobbs-qSBHQ2]

This is just a shot in the dark but what happens if you explicitly scope all of your variables so that qGetJobs becomes variables.qGetJobs and Notes becomes variables.qGetJobs.Notes ?  "Client" is a reserved word since CF has a Client scope.  You may need to refer to this as variables.qGetJobs["Client"].

[JocularGargoyle]

Apparently the fix for this particular issue is to uncheck 'Maintain connections across client requests' in the Advanced settings for the ColdFusion DSN. This hardly seems ideal since every request will have to open a connection, do the query, and close, but I suppose that's preferable to the occasional error. Thank you, everyone, for your help!

[TLC-IT]

It might be... but what if instead you catch the error (if it occurs) and do something to deal with the error on the rare occasion when it happens?

From your description, it seems that the problem is "the connection has been lost."  Okay, that's a very-occasional thing (so you say...), doesn't happen too often, and so the real issue (one might say...) is that the end-user sees it happening with a very-ugly error message.

If you frame the logic in a try..catch block, the exception will be trapped when it occurs and then you can take whatever recovery-action you might need to do (e.g. re-establish the connection and try again...).  Most of the time, the exception doesn't happen and you just go on your merry way, having not wasted any time laboriously checking to see whether the error happened or not.  You just stick someone out there in right-field to catch the ball if, this time, it happens to "go foul."  It costs next-to-nothing to post him out there, and he only has something to do when-and-if "the rare circumstance that he is looking for" actually happens.  (You don't have to say ... "if the ball went foul then..."  If the ball went foul, as it does 2%-or-less of the time, then your right-fielder unerringly catches it and that's how you know.)

Offhand, I think that this would be a lot less costly than maintaining a bunch of connections.  (I opine that such an approach would prove to be a decision that you regret for other reasons.)

The term, "exception," is well-named.  Take advantage of them.