E-mail-based error reporting, whether from a system specifically designed to provide it (like Nagios) or as a bolt-on to an application or framework, is only as good as the underlying error diagnostics. So when one of our clients’ Coldfusion app sent me a message today with the brief summary “null null”, the server might as well have been sending me smoke signals. Actually, smoke signals from a server would have been a good deal more worrying.
When the error message itself is unilluminating, then it’s a fair bet that a number of people have already looked to online fora for illumination. A quick Google provided me with an explanation for the error, at least:
…the problem occurs when CFERROR is used for custom exception handling and a Null Pointer Exception occurs at runtime. This causes the cferror variable error.diagnostics to be populated with the value of “null null”. Normally, error.diagnostics is the concatenation of cfcatch.message and cfcatch.detail….
and to understand is, at least partly, to sympathise. And, in this case, to understand further: coupled with the line number on which the error was reported as happening—minus 1—the error message implies some sort of before-execution corruption of variables or memory space. The most likely culprit is the CLIENT variable scope, which is used in the application, given that a number of minor, almost untraceable errors arise from the junction between code- and database in this (admittedly quite old) app already.
Exit gracefully: if the error diagnostics contain “null null”, error reporting will add a stack trace. This should confirm any future errors as being caused by a corrupt CLIENT scope and we can consider applying patches and updates to militate against it.
