Select Page

Considering The “Bounded Context” Of Error Messages In A ColdFusion Application

Cyberdime
Published: October 25, 2022

Error handling in a web application is a deceptively hard concept. I’ve been building ColdFusion applications for two-decades, and I’m only just now starting to feel like I’m finding helpful patterns that balance complexity and utility. And, I still have so much to figure out. As I’ve been refactoring / modernizing the code for my ColdFusion blog, I keep running in to unanswered question. My blog has both a public facing system and an admin facing system; and, I’m starting to wonder if these are two distinct bounded contexts for errors and error messages.

ASIDE: As I’ve been refactoring my ColdFusion blog, I’ve been slowly cleaning up the code and trying out different organizational and control-flow patterns. Here are a few articles that are highly relevant to this conversation:

My refactoring has, to date, focused almost entirely on the public facing portion of this blog. That is, the portion that the “users” interact with. As such, all of the error messages have been about “first person” data. That is, “Your” data. So, if a user goes to leave a comment and the name field is empty, the error message reads:

Please enter your name.

Now, in the admin facing portion of this blog, I have the ability to edit comments as you’d expect. And, what I’d like is for both the public and the admin facing portions of the site to use the same domain model. That is, I want to share the layer of the “application core” that determines that a “name” can’t be empty and still be valid.

The problem is, if an admin (Me) goes to save a comment without a name, I want the error message to read:

Please enter the author’s name.

Unlike in the public facing portion of the blog, where I’m talking to the user, within the admin I’m talking about the user. As such, the error messages should be different.

In my first post about centralizing error handling on this blog, my plan would have been to catch-and-wrap errors in the Workflow layer. Meaning, within the Admin facing workflows, I’d catch the “empty name” error and then throw a new error specific to the Admin-facing workflow. This error could then be handled in the centralized error handler and be given a unique error message.

Catching-and-wrapping as a rule turned out to be overly tedious and syntactically verbose. I was wrapping things just for the sake of making error messages more flexible. But, now I’m wondering if it even makes sense for the public facing and admin facing applications to share the same error handling? If the two applications had completely separate error boundaries, then I could map the same domain error onto two different error messages.

NOTE: I’m not against catching-and-wrapping errors when it makes sense. I’m just no longer convinced that it makes sense as often as I had originally thought it did.

Meaning, in the public facing error handling ColdFusion component, I could have:

component {
	public struct function getResponse( required any error ) {
		// ... heavily truncated snippet ...
		switch ( error.type ) {
			case "BenNadel.Entity.Member.Name.Empty":
				return(
					as422({
						type: error.type,
						message: "Please enter your name."
					})
				);
			break;
		}
	}
}

And, in the admin facing error handling ColdFusion component, I could have:

component {
	public struct function getResponse( required any error ) {
		// ... heavily truncated snippet ...
		switch ( error.type ) {
			case "BenNadel.Entity.Member.Name.Empty":
				return(
					as422({
						type: error.type,
						message: "Please enter the author's name."
					})
				);
			break;
		}
	}
}

Note that the same error.type value is being mapped onto two different error messages.

Once I let my mind start to think about having two distinct error handling services, other things started to make more sense. For example, the routing within the two different applications is completely different. Also, one system has session management, the other does not. What this means is that the two different error handling services will change for different reasons. Which is another “smell” that they should be two different “things”.

I’ve only just begun to refactor my admin. So, we’ll see how this thinking plays out in the code. I’m also concerned that my desire to share any code between the public and admin facing portions is ill-fated. After all, it’s that what a “bounded context” is? A separation of the definition of what things are? That said, I do think there is value to having some fundamental truths about the data be shared across the two systems.

Check out the license.

Source: www.bennadel.com