Make sure the validation queue does not freeze when an error occurred during validation.

[Svelix]

When an exception is thrown during the validation of any item, the validation queue is stopped because _isValidating will stay true forever.

We show an error dialog to our users when an uncaught exception is thrown. Unfortunately this error dialog is never shown correctly cause it will not be validated in this case.

I added a simple try..finally block to the validation queue to prevent this scenario. This way the error is handled the normal way and the next time the validation is triggered it will continue normally with the item that is after the one that caused the error.

[joshtynjala]

While this seems like a good idea to help reduce the impact of runtime errors, the performance impact would be too severe. It's already too easy to create slow content. Even if it's only 30%, and not 2-3x, that's brutal on low-end devices.

I wonder if a temporary uncaught error listener would offer the same advantage without the hit on performance.

[Svelix]

I am always guarded when it comes to as3 performance tips that are based on tests that are made 4 years+ ago. So I took the the code from the first link you provided and put it into an AIR app build with AIR SDK 13.

This are my results in a Desktop App:
No try-catch: 9777
Try-catch: 9713
No try-catch: 9702
Try-catch: 9842
No try-catch: 9720
Try-catch: 9897
No try-catch: 9710
Try-catch: 9868
No try-catch: 9898
Try-catch: 10119

And this are my results in a mobile App running on a Galaxy S3:
No try-catch: 2111
Try-catch: 2106
No try-catch: 2094
Try-catch: 2087
No try-catch: 2105
Try-catch: 2092
No try-catch: 2116
Try-catch: 2084
No try-catch: 2082
Try-catch: 2098

I have no idea why the desktop version is that much slower than the mobile one, but as you can clearly see there is no big difference between try-catch and no try-catch when used with up-to-date compilers.

[jamikado]

Except that you should also probably do a test with a version compiled for iOS .ipa using a release build, since iOS converts these try/catches into native versions and you probably can't make the same assumption about the results above when it comes to iOS

[joshtynjala]

On Windows 8.1, I can confirm that try-catch doesn't seem to have the performance impact it once had. I haven't tried other platforms yet. iOS would be the most interesting, as Jeff mentioned, since it runs AS3 so much differently than other platforms.

Jackson Dunstan also has an article about performance penalties when using finally (from 2012, this time). I can reproduce a performance difference with the code posted there.