Triggering onInvalidEvent from within handler

Hello Guys,

I’ve configured onInvalidEvent and it’s work just great! (that was very easy)

Now, what I want to do is trigger onInvalidEvent behaviour from other events, in a similar manor to setNextEvent.

For instance, let’s say a user looks at an event like this /index.cfm?event=someValidEvent&some_id=InvalidID

I want to recognise that the ID isn’t a valid one, using some logic in my handler, and then throw the invalid event.

I’m currently doing it like this, using runEvent() which works great!

public void function view(any event) {

// TODO: We need to find some method for securing this, to stop users from viewing one anothers services.

// One way suggested to do this is to pull the view by ID scoped to the account, this would be easy in rails, cf, not so much.

// Grab the event collection from the event.

local.rc = event.getCollection();

// Collect the servie entity for diplay.

local.rc.service = serviceService.get(local.rc.service_id);

// Check to ensure that this service exists.

if (isNull(local.rc.service)) {

// A service was not found matching that ID.

// Route them to the page not found event.




My only concern with this is that if I change my 404 event handler to something else, then I have to go through the application changing these references.

Is there a better way of doing this? or could there be? What about some form of facade method like invalid() which triggers this behaviour? Any suggestions?



I would recommend implementing an onInvalidEvent interceptor. You can override the current event handler bean from within that interceptor. Then you can ask the interceptor service to fire that interception point in places of your choosing as well. In case you were curious, the onInvalidEvent interception point is called prior to running in your invalid event handler.

Thanks Brad, that sounds like a nice way of doing things.I’ll look at doing something like that.

Thanks mate.


Hi Brad,

I’m looking at this again this morning and thought I’d come back to you for your opinion again.

I don’t like having to do a conditional to check if the returned value is Null, as this seems like logic which would be better handled elsewhere. (cross cutting concern)

In an ideal world, I think I’d have the service layer throw an exception when a record isn’t found, something like ‘orm.RecordNotFound’ which could then be caught and dealt with application wide, passing the user to the pageNotFound event, rather than having to put the conditional in every handler method, seems logical, right?

Unfortunately, the VirtualEntityService returns null rather than throwing an exception, so the conditional feels my only choice.

What do you think to that?



I know what you mean about it not feeling quite right having to check for a null there. There’s nothing really wrong with a method returning null in a certain situation as long as it is documented and your code is prepared to handle it. As a long-time CF guy, nulls are a little uneasy for me to deal with anyway just since the language didn’t really even support them for a while. Luis is has a Java background and they eat null values every day for breakfast so he’s not scared to use them. :slight_smile:

Seriously though, my one thought about throwing an error is that errors are costly to throw IF you’re planning on doing a lot of them. If this is something that will happen once in a while, then there’s probably no concern. As far as HOW you would accomplish that, I’ll admit I haven’t gotten into the CF ORM stuff yet and likewise I’m not really familiar with the VirtualEntityService. I think it’s possible for you to extend the VirtualEntityService however. Can you override the method(s) in question, call super.blah(), and then cfthrow where you want to? That, in theory, will allow you to modify the behavior of that service for your purposes.



Hi Brad,

I agree, there is nothing wrong with null values, they can be pretty helpful.

These exceptions won’t be used very often, so the cost isn’t such a big deal! The only reason I prefer them is that:

A) they force you to handle them, you could miss handling a null and the app would come fairly quietly.

B) they can be caught and handled app wide from a single point.

I think extending the base service will be my best option for this, I may also talk to Luis about some form of config option on the entity service which makes it more verbal when records aren’t found, for those that may want if.

I will put together some proof of concepts and see how it goes.