Funny, but I’ve had this screen many many times when accessing MXNA.
I wonder how many sites (let alone high profile sites) don’t have a default error handler in place.
Exception handling (be it with cftry/cfcatch or cferror etc) is often the last thing on a developers mind. It’s easy to assume that things won’t go wrong or the user will enter the correct data in a form.
One of the things I strive to do as a developer is to think of the worst case scenario, or to think like a hacker/malicious user. What would they do to break my site?
Would they turn off javascript? In that case I need to make sure I have server side validation to backup my client side validation.
Am I referencing scoped variables? Maybe I should <cfparam> them.
In the event of certain exceptions I may need to alert the site administrator of the error via email, a handy feature when using <cferror>
Either way a user seeing an error message is bad whichever way you look at it. It looks amateur and could potentially give away vital information for would be malicious users.
As such, exception handling it should be a mandatory part of any coders development methodology. Whether you use a granular approach like <cftry> or not, you should implement <cferror> to catch any exceptions that slip through the net.
MXNA actually does use a few types of error handling, and has a pretty sophisticated default error page, however the application can get into a state where even the error page can fail, which is what you ran into. Basically, it happens when the application starts receiving too many requests before it has been fully initialized. It’s definitely a bug, and I should find some time to fix it.
Christian
Christian Cantrell
December 20th, 2006
Nice one Christian, thanks for the explanation!
Have a great Christmas
Michael Sharman
December 21st, 2006