> it absolutely should not do anything like this by default
I appreciate your opinion on the matter, but I’ll have to disagree. People use frameworks because they do things for them. If a framework doesn’t make your life easier, why would you bother using it? Every CF framework I’m familiar with catches errors in your code in a similar fashion. Frankly, in the years I’ve been on the ColdBox list I’ve never heard anyone else complain about the ColdBox error handling, which if I might add, by default displays more ColdBox-related information and is therefore more helpful than the standard CFML engine’s error message. It seems the vast majority of people want to use the framework’s error handling capabilities, and we’re not going to change that default behavior.
To turn the tables on you a bit, I would ask you this question: If you didn’t want ColdBox catching your errors, why did you allow them to bubble up to the framework in the first place? Wrap a try catch around all your code and ColdBox will never touch your errors again. That sounds rather painful to me though. I’d really rather just embrace the incredibly helpful and flexible tools that ColdBox gives you to deal with your errors.
If you really want the exception to reach the CFML engine, this can be accomplished very easily with the following simple interceptor I just threw together. All it does is listen for exceptions and rethrow them.
/interceptors/rethrow.cfc
component {
function onException(event, interceptData) {
throw(object=interceptData.exception);
}
}
/config/ColdBox.cfc
interceptors = [
{class=“newApp.interceptors.rethrow”}
];
> CB returns doesn’t even set the HTTP response code to be 500. It’s a “200 OK”.
Yes, that’s correct. That would be because the application has recovered from the error and returned useful HTML that it wants the browser to render. Returning a 500 would make many browsers (at least IE, I know) show a “friendly” error message of its own which would defeat the purpose of your error template. If you would like a different status code, you can easily configure it in your error handler.
> Even if I put my own onError() handler into my Application.cfc, I still get CB’s error handling.
That is because errors only bubble up this far if the actual framework errors out (or you rethrow it as the interceptor above shows). The Application.cfc’s onError() is basically a last-ditch effort to handle the error before it makes it to the CFML engine. It’s not an ideal location to deal with an error though since it’s outside of the framework’s life cycle and therefore not easily capable of running framework events, using logging facilities, or rendering views. It’s far more productive to catch and recover from errors while still inside the framework.
None of this explains why your ‘throw “exception0”;’ code does not appear to be executing though and I’m not sure how to help you there. Like I said in my previous E-mail, it works perfectly for me (exception is thrown and picked up by the framework so I can deal with it with a handler onError(), an onException interceptor, or an exceptionHandler, or a customErrorTemplate.) Perhaps you can zip up your sample app so we can try it.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com