Blog

ColdBox 4.0 Error Handling

Brad Wood January 29, 2015

Spread the word

Brad Wood

January 29, 2015

Spread the word


Share your thoughts

ColdBox has always provided nice, automatic error handling for your code.  Errors in your application are caught for you, and you can respond to them via convention-based methods, event handlers, or even interception points as you see fit.  (Read more on ColdBox error handling here)

If you do nothing, ColdBox will render a nicely formatted page with all the original exception information plus extra details about the ColdBox request which can be handy for debugging.  Due to our focus on security-by-default in ColdBox 4, we found that a large  number of people never change the default error template and their production servers give out way too much information!  Even though having a 'detailed' template by default was convenient, it wasn't secure.  

Therefore, we now ship ColdBox with two error templates.  (Of course you are still encouraged to make your own custom ones.)

  • BugReport.cfm
  • BugReport-Public.cfm

Get Your Info Back

BugReport-Public is what is enabled by default.  It outputs very little information so the baddies can't use your default error template as an attack vector to gather information about your server.  Don't worry though, the original error template (BugReport) is still there and can easily be enabled at any time. 

To get your old error template back, simply add the customErrorTemplate setting in your /config/ColdBox.cfc like so:

coldbox = {
	customErrorTemplate = "/coldbox/system/includes/BugReport.cfm"
};

Note: you can point to any valid .cfm file with this setting.  Feel free to create your own themed error template that matches your site's layout.  Just remember, this is not a view-- just a stand-alone .cfm file that can only access the variables.exception object.

An Even Better Way

We don't recommend just changing the setting like that because you're likely to forget and put yourself back at square 1 again when you push your code to production.  What's best is to leave the production error template to a 'secure' one and add a development override that only uses the public template on your development servers.  

coldbox = {
	customErrorTemplate = "/includes/myCustomPrettyErrorPage.cfm"
};

environments = {
	development = "localhost"
};

function development(){
	coldbox.customErrorTemplate = "/coldbox/system/includes/BugReport.cfm";
};

Now, your default production setting is your custom pretty error page, but on your dev server you get the juicy details.  Make sure you've also configured some LogBox logging on production so you have some way to get your error messages!

Read more about ColdBox 4 compatibility here:

http://wiki.coldbox.org/wiki/Compatibility:4.0.0.cfm

Install ColdBox 4.0 with CommandBox today with this simple command:

CommandBox> install coldbox

Add Your Comment

Recent Entries

QR Codes Come to BoxLang Images

QR Codes Come to BoxLang Images

The bx-image module can now generate and read QR codes. Two new functions, a string member function, and two new bx:image actions. No extra dependencies for you to manage.

Luis Majano
Luis Majano
October 14, 2026
ACF2021 extended support ends on November 10. Is Your Application Ready?

ACF2021 extended support ends on November 10. Is Your Application Ready?

Adobe ColdFusion 2021 reaches the end of extended support on November 10, 2026. If your application still runs on this release, the time to decide what comes next is now.

Adobe ended core support for ColdFusion 2021 on November 10, 2025. The current extended support period is best effort and does not include security patches or hotfixes. When it ends on November 10 2026, organizations will no longer have that support option from Adobe for ColdFusion 2021.

What ...

Cristobal Escobar
Cristobal Escobar
October 13, 2026