A Closer Look At Error Handling During Parallel Array Iteration In Lucee CFML 5.3.6.61
I've looked at using parallel array iteration in Lucee CFML before; I've even mentioned that the errors during parallel array iteration bubble-up to the parent page request. But, my mental model for error handling during parallel array iteration hasn't yet been fully formed. At least, not in a way that I can immediately summon it to the forefront of my mind. As such, I wanted to take a moment and look specifically at what happens when an error is thrown during parallel array iteration in Lucee CFML 5.3.6.61.
To test this, I'm going to create an Array, iterate over it using parallel threads, and throw an error during each iteration. The first error should bubble-up to the parent page, as I mentioned above; but, we'll see if the rest of the array is processed:
<cfscript>
// Setup our test collection - the contents of the collection are irrelevant - we
// just want something we can iterate over in parallel.
values = []
.resize( 10 )
.set( 1, 10, "test" )
;
try {
values.each(
( value, i ) => {
systemOutput( "Processing index #i#", true, true );
throw( type = "Ooops, #i# is wonky!" );
},
// Perform iteration using parallel threads.
true,
// Using ONLY A SINGLE THREAD - this way, we can isolate the error behavior
// at the thread-level, and not get confused about what might be going on at
// the iteration level.
1
);
// CAUTION: We should NEVER GET HERE since the error in the parallel array
// processing will have bubbled-up to the top-level page and triggered the
// try-catch block.
echo( "Array processing complete." );
} catch ( any error ) {
echo( "Error processing array: #error.type#" );
}
</cfscript>
As you can see, during each iteration we're throwing an error. The first error immediately halts the top-level, parent page request and outputs the following:
Error processing array: Ooops, 1 is wonky!
However, when we jump over the terminal, which contains our systemOutput() calls, we see the following:
Processing index 1
Processing index 2
Processing index 3
Processing index 4
Processing index 5
Processing index 6
Processing index 7
Processing index 8
Processing index 9
Processing index 10
What we can see here is that - even when using a single thread to perform the parallel iteration - the ColdFusion runtime keeps processing the Array indices after an error has been thrown. So, basically, when using parallel iteration, there's no stopping the iteration mechanism once it has started, even if the parent page request has been terminated.
This is good to know; and, is not necessarily the way I was thinking about this working. But now, I have the right mental model and will be able to better leverage parallel array iteration in Lucee CFML going forward!
Want to use code from this post? Check out the license.
Reader Comments
This is interesting but isn't what I'd expect either. Does this seem right to you? I can't think why it would be harmful except that it's consuming resources unnecessarily by processing the remainder of the array. And I can't think of any examples where it might be useful to do so. Or even how I'd use this knowledge to my benefit. Do you?
Feels like this would be neither the desired nor the expected result.
@All,
I've started to coalesce around a pattern in which I use a parallel
map()operation, and catch-and-report errors for each iteration. Then, I can report errors back to the user (where and when it makes sense):www.bennadel.com/blog/4067-managing-and-reporting-errors-during-parallel-array-iteration-in-lucee-cfml-5-3-7-47.htm
I just love how easy ColdFusion makes some types of parallel programming.
So, I had forgotten that I wrote this post and I accidentally re-explored the topic this weekend. And, it's a curious thing because it seems that the Lucee CFML behavior has actually changed since this original post. Now, it seems that Lucee CFML will short-circuit the parallel iteration when an error is encountered:
www.bennadel.com/blog/4573-follow-up-on-error-handling-during-async-iteration-in-coldfusion.htm