Speak of the Devil

I was talking recently about "duck typing" and how it is that strict-typing (at least in ColdFusion) really doesn't do anything for you except create errors in a bad way because the error creation is indiscriminate. We already know that performance isn't a benefit for strict-typing with ColdFusion, and even if it were my advice would be to ignore it anyway.

So I'm working on these ports of Ray Camden's Galleon Forums application and I've got the Mach-II port nearly working. I log in to the administrator and get this error message:

If I were only slightly less knowledgeable about OO, this might have been a real WTF moment.

I've actually created an application-specific mapping to /MachII in the Application.cfc for this port, which targets an original, unmodified copy of the current release of MachII to ensure that my ported application will always work on ColdFusion 8 in spite of later releases of the framework.

So that being the case, I can only assume that since eventContext is the original unmofied Mach-II object, if it's not returning an Event object, it must not have an object to return. Sure enough, eventContext.hasCurrentEvent() returns "NO".

That's not the problem though -- or at least not the one I'm talking about right now. The problem is that the return type of the getCurrentEvent() method in the eventContext object is "MachII.framework.event" so when it doesn't have anything to return or when it returns something other than an object of that type, it throws this error.

I wouldn't normally even receive this error because if I were just using events and listeners, the framework would throw a much more helpful "I can't find this event!" message, which tells me exactly what's wrong. But in this case, the error is being thrown in a plugin that executes code prior to any of the events and the architecture is designed to allow these plugins to run even if the event isn't found, allowing you to do things like redirect the browser to a friendly "Sorry, the page you're looking for can't be found" message. That's the reason why they added the hasCurrentEvent() method.

My point is this: even though I can use hasCurrentEvent() to resolve my issue, the type-checking error being thrown by ColdFusion's native features is much less helpful than the error that would have been thrown if the return type had been ducky (any).

If the return type had been "any" then I'd have likely received an "getArgs is not a function" or "getArgs can't be found in object of type String" or any of a number of similar variations that would have told me immediately that, "gee if the function isn't defined, maybe I should dump it out and see what's being returned". If it were actually returning an object, then either one of two things might happen - it might be the wrong kind of object (not very likely) and throw the "method not found" error, or it might return an object which due to mapping variations might not actually identify itself as a "MachII.framework.Event" object in which case there wouldn't be any error because it would actually be that object in spite of the fact that it claimed to be something else.

By comparison with the "is not of type MachII.framework.Event" error, my very first gut response is "WTF? It's your object! Don't tell me there's a problem with the mapping!..." But I can't just dump out the results and see what type of object it's claiming is returned (how it's mapped) because it throws the error instead of returning it. If the return type were "any" then I'd be able to dump the returned value and see that it's a string or an empty structure, etc. and likely assume that the event handler wasn't defined. As it is if I wanted to dump the value, I'd have to edit the MachII core files. I'm fortunate that I figured it out without doing that.

This is what I mean by the indiscriminate creation of errors. The type checking creates an error and you might say "hey, great! It knows there's something wrong", but a discriminating examination of what's actually happening at that moment shows that just about any error other than the type-checking error would have been more helpful.