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.