I am trying to find out where and what line an error is happening on. However the stack trace points to coldbox.
Here is what I mean:
I get the following stack trace (However I happen to know that the error is actually happening somewhere in D:/websites/webpanel/model/global.cfc)
The error occurred in D:/websites/webpanel/coldbox/system/ioc/Builder.cfc: line 123 Called from D:/websites/webpanel/coldbox/system/ioc/Injector.cfc: line 288 Called from D:/websites/webpanel/coldbox/system/ioc/scopes/NoScope.cfc: line 31 Called from D:/websites/webpanel/coldbox/system/ioc/Injector.cfc: line 261 Called from D:/websites/webpanel/coldbox/system/ioc/Builder.cfc: line 547 Called from D:/websites/webpanel/coldbox/system/ioc/Builder.cfc: line 99 Called from D:/websites/webpanel/coldbox/system/ioc/Injector.cfc: line 288 Called from D:/websites/webpanel/coldbox/system/ioc/scopes/NoScope.cfc: line 31 Called from D:/websites/webpanel/coldbox/system/ioc/Injector.cfc: line 261 Called from D:/websites/webpanel/coldbox/system/web/services/HandlerService.cfc: line 120 Called from D:/websites/webpanel/coldbox/system/web/services/HandlerService.cfc: line 141 Called from D:/websites/webpanel/coldbox/system/web/Controller.cfc: line 550 Called from D:/websites/webpanel/coldbox/system/Coldbox.cfc: line 74 Called from D:/websites/webpanel/Application.cfc: line 86
My bet is that if you open up Builder.cfc and take a look at Line 123 you’ll find that it is nested inside a try/catch. Comment out the try/catch and let the raw exception bubble up.
Matt is correct. There is a cfcatch that catches errors building mappings and rethrows them. The reason we don’t let the original error bubble up is because it gives you no context about how/where the error happened or what mapping was being created. Here is what our cfthrow actually looks like:
You can see the original error message, detail and stack trace are included in the new error, but we add in the name of the mapping, constructor args, and mapping details as well. Unfortunately, we can’t suppress the stack trace that simply points to this line since this is where we are rethrowing. What would be idea here is if CFML allowed for exceptions to have a cause like Java does where you can simply wrap the original exception in an outer one but we can’t do that.
So basically, in this specific case, you need to ignore the stack trace proper value of the error, and pull the actual strack trace out of the error details.
This is especially true for any DSL error, I wish it could make the error more meaningful. In your case it is very clear what the error is though, I would search for the CHUNK and see why it says I have it already defined in the arguments scope. This usually means that you are trying to use a variable locally that is already defined in your arguments scope.