Mysterious Error Handling Behavior With Proxied Futures In ColdFusion 2018

@All,

It's even easier to see the oddities here if you pass the Future through an echo() method:

<cfscript>
	
	public any function echo( required any value ) {

		return( value );

	}

	future = echo(
			runAsync(
				function() {

					var inner = runAsync(
						function() {

							sleep( 2000 );

						},
						100 // <------ THIS WILL TIMEOUT!!!
					);

					return( inner.get() );

				}
			)
		)
		.then(
			function() {

				return( "then-value" );

			}
		).error(
			function() {

				return( "error-value" );

			}
		)
	;

	writeOutput( future.get() );

</cfscript>

When we do nothing else but pass the runAsync() result through the echo() method, it breaks the error-handling.

If this is really the way error handling works -- and I'm not just missing something obvious -- then this is likely going to be the biggest hampering of the Future functionality. It essentially means you could never create access methods that return Futures; otherwise the calling context won't be able to use the .error() bindings.

@Edward,

Take a look at one of the comments I left though -- you can "break" the error handling by simply passing the runAsync() response through an echo() method. I think that more clearly demonstrates the problem since the echo() method should not change the functionality.

@Vijay,

Ok cool-at least I'm not going crazy :)

@Vijay,

The most obvious one to me is that you may have Gateway / Service methods encapsulate the logic of making some sort of request. So, for example, imagine you have a "remote API" to call. You could have Gateway methods like this:

public any function getThingByID( id ) {
	return( apiClient.getByID( id ) );
}

public any function getThingByIDAsync( id ) {
	return(
		runAsync() {
			return( getThingByID( id ) );
		}
	);
}

This would now allow you to consume the remote API either as a blocking call:

try {
	var thing = thingGateway.getThingByID( id );
} catch ( any error ) {
	// ....
}

... or, as a non-blocking, asynchronous call:

thingGateway.getThingByIDAsync( id )
	.then( ... )
	.error( ... )
;

However, in the latter case, the calling context cannot really "leverage" the Future in a natural way since the .error() won't catch the error properly.

Essentially, this completely eliminates a whole swath of encapsulation / abstraction choices.

@Vijay,

Also, what if you want to try to build more async functionality around the concept of Futures. So, forget about the "remote API" -- what if I wanted to build something like this:

var future = futureAll([
	getFutureA(),
	getFutureB(),
	getFutureC()
]).error(
	function() {
		// ....
	}
);

... where I might want to take an Array of Futures and wait till all of them are resolved in parallel (as opposed to in serial using .then()). This is what Promise.all() does.

Then, the concept of "Racing":

var future = futureRace([
	getFutureA(),
	getFutureB(),
	getFutureC()
]).error(
	function() {
		// ....
	}
);

... where I want to use the first fulfillment and ignore the rest. Again, coming from the Promise world, there a lot of Promise.race() implementations.

In each of these cases, we don't care how or why the Future objects are being created -- we're just trying to build functionality around managing those futures. But, if we encapsulate that logic (which would likely be complicated logic) inside a Function, then we lose the ability to use the returned Future in a natural way.

@Ben,

Again, the underlying thought here is that if you don't allow proxies Futures to behave like Futures, then you limit the creative ways in which people can use Futures.

But, to be fair, I know nothing about how Futures work in Java. I only know Promises in JavaScript. So, maybe there are a lot of limitations in Java that make this kind of stuff difficult.

@Vijay,

Groovy. It's also possible that Futures are not really intended to be "composed". After all, there is still a lot of value in simply being able to run a few methods in parallel. So, I don't want to sound like I am diminishing the work. Honestly, at the end of the day, if I can do:

var a = runAsync( getSomeData );
var a = runAsync( getSomeData );

... oops, hit ENTER too soon.

... Honestly, at the end of the day, if I can do:

// Run these all in parallel !!
var a = runAsync( getSomeData );
var b = runAsync( getSomeData );
var c = runAsync( getSomeData );

var aData = a.get();
var bData = b.get();
var cData = b.get();

... that's still awesome and will have huge performance implications :D

I'm just trying to dig in and see all the fun things that we can try to do with this.

@Vijay,

Woot woot, #TeamWork :D

@Vijay,

I've tried to put together a more interesting demonstrate of why I might want to create a Future inside a Function and then return that Future and have the .error() method work "as expected":

www.bennadel.com/blog/3495-experiment-creating-a-promise-inspired-future-constructor-in-coldfusion-2018.htm

Hopefully this kind of post sheds some light on where my brain is going.

@All,

Ok, so I found an even more crazy issue. Which may actually be the root-cause of the issue in this "proxy method" post. It turns out, the very act of storing a Future in an intermediary variable will break error handling:

www.bennadel.com/blog/3496-saving-a-future-in-an-intermediary-variable-breaks-error-handling-in-coldfusion-2018.htm

So, it's very possible that what is breaking the proxy-method is the fact that the Future gets stored in a method-argument? At this point, I wouldn't know how to test these two errors independently.