No, ColdBox is not going to simply rethrow the errors so Cf can show it’s ugly default error message. I wouldn’t want it any other way. Good applications show friendly error messages that don’t reveal the internals of your app. ColdBox starts with a developer-oriented message with much more info than the a standard cf error and there are a number of mechanisms the framework provides for you to intercept errors and either recover from them or display a custom error template (which can be different in production with a simple environment override).
Hopefully that helps explain how and why coldbox help you deal with errors. As far as why your specific exception isn’t being caught, I’m not sure at the moment without getting a chance to look closer at the code woke in front of my computer.
“Good applications show friendly error messages”… I’m all good with with it providing the mechanism to deal with errors better, same as CF does (and IIS, etc). But it absolutely should not do anything like this by default. For one thing, the “good application” in this case is the code I’m writing. CB is just a framework: it should not be doing anything unless it’s told to do so. The default behaviour should be to just stay out of the way unless it’s advised to do otherwise. IE: provide the functionality, don’t enforce the functionality.
Systems that do stuff they’re not asked to do are annoying, not helpful.
I also note that this default error response CB returns doesn’t even set the HTTP response code to be 500. It’s a “200 OK”. So not only does it interfere when it’s not asked to… it doesn’t actually do the job properly. Not a “win” for ColdBox, this one.
[groan]. Even if I put my own onError() handler into my Application.cfc, I still get CB’s error handling.
Hmmm. [wheels turn in his head]. One consideration in all this is that my app is not set up to inherit from CB’s app, it’s using option 2 on this page: http://wiki.coldbox.org/wiki/Bootstrapper.cfm. This is because my CB mapping is done in Application.cfc, so I can’t have Application.cfc extend coldbox.system.Coldbox because it doesn’t know where CB is until after it needs to already know. So it makes sense that setting my on onError() doesn’t help to deflect away from whatever CB is doing. It makes sense. But it’s not helpful.
How do I stop CB from being “helpful” here? I think it’s perhaps best if dealing with exceptions is left up to me, in this instance.
Actually Adam you are wrong on this, please let me explain why.
Status codes, ColdFusion will return whatever status code you tell it to return. By default, that means 404 and 500 types if you have it selected. During development you should never have that enabled in your CF Administrator, because there are times when IIS will take over and you will never see the error message.
ColdBox is very helpful in this regards, because it is trapping all errors for logging in one place only, your defined logger. Sure it is an exception handled template with a different look and feel, but that is all it is. And it is up to the developer to them decide if they provide the appropriate error handling in handlers and such.
Having the logs all in one place is far better than remembering to check the CF logs as well as ColdBox logs, so it boils down to what you are used too.
But if you remove the setting from ColdFusion about returning status codes, you will get the standard 500 error code, and again I can not iterate how important it is that this be switched of in development.
Which means that the frameworks you mentioned, DO NOT SET THE RETURN code, and let ColdFusion do this. Which now means they can’t be good applications by your definition, because they don’t set return codes.
That should be if you don’t remove the CFIDE setting