RE: [coldbox:17106] [ColdBox 3.5.2] Exception "handling" weirdness

> I shouldn’t imagine it’s a problem on Railo, but have not tested yet.

I was using Railo 4.0.2 at home when it worked, so I guess that confirmed that Railo does not have that bug.

> However if there’s an error in my code (like me specifically doing a ), then you should leave it the hell alone and let it error. It should be up to me what gets done about this, not CB.

I guess that’s the thing-- you have a chance to catch your own errors in your beans, services and handlers all you want. If you fail to catch your errors and let them keep bubbling, ColdBox is going to catch them for you since exception handling is a core feature of ColdBox. I’ll tell you what-- you can put in a ticket to have a framework setting to rethrow errors up to the CFML engine, and possibly even make that the default and the ColdBox team will discuss it. We might add a setting to disable all exception handling but I doubt we’ll make it the default.

> Am I correct in thinking that whenever an event is fired / announced / whatever, then all the interceptors are looped over to see if they have a matching method (where “matching” is “a method with the same name as the event”)?

Yes, that is basically correct. When I describe interceptors I stray away from the word “event” just so not confuse it with a framework event-- i.e. an action (or method) in a controller (or handler cfc) which is run based on a URL route or explicit runEvent() call. Interceptors are a separate event-driven construct within ColdBox that allows multiple subscribers to listen to the same interception point. Here’s some links on them:

> …is there a reason you took that approach instead of the more traditional approach of having a mechanism wherein a handler is registered to listen to the event

I’m not sure if I understand the question. It is possible to put an onError() method in a handler, but that would only be triggered for errors in that handler. It is also possible to specify a site-wide ColdBox event to run in case of an error, but I don’t think that fires for proxy calls since they live outside the normal request lifecycle. The onException interceptor point is just my preference for the easiest lightweight place to handle all errors in your application. What you said above is essentially what I did if you replace the word “handler” with “interceptor” and the word “event” with “interception point”, but at that point it’s just a matter of what terminology you’re using.



ColdBox Platform Evangelist
Ortus Solutions, Corp

ColdBox Platform: