As you use iterator functions (and yield) more and more, you’ll start to run into some limitations in the C# language. For instance, you can’t yield inside a try block that has a catch block. And the foreach loop doesn’t provide a very good way to catch exceptions when looping over an iterator function, either. Today’s article goes into detail to find solutions to these issues and make iterator functions usable in even the trickiest scenarios!
Posts Tagged try
Continuing the series on C# syntax, today we’ll look at the differences an AS3 programmer can expect to encounter when using conditionals (if/else, switch/case/break/goto) and exceptions (try/catch/finally/throw). We’ll also look at iterators, an all-new category for AS3 programmers that empowers us to both iterate however we want and to write coroutines, a kind of lightweight pseudo-thread.
Try as I might, I just couldn’t find any articles about AS3’s finally keyword. Sure I found Adobe’s documentation, but it seems no one is commenting any further about finally. So today I’ll tackle the performance of what seems to be a straightforward keyword. Could it possibly cause a slowdown? Read on to find out!
During some recent memory profiling I was reacquainted with just how many ways there are to unknowingly allocate an object in AS3. The problem is seldom the allocation itself, but rather the later garbage collection (GC) to delete those objects. Ever used a Flash profiler only to see a huge chunk of your CPU time going to [reap], [mark], or [sweep]? Yeah, that’s the GC at work. Today’s article talks about some of the ways you end up allocating objects in AS3 without using the new keyword. These subtle errors can end up costing you!
Today’s article is a followup to an article (Cast Speed, itself a followup to Two Types of Casts) from September that continues to gather comments. Sharp-eyed reader fastas3 brought up a good point that warranted some further investigation into the topic. So today we’ll be taking yet-another look at typecasting in AS3 to try to unravel some of its strange mysteries.
Today’s article is in response to a comment left about my article on try/catch slowdowns. The second time around I will provide an example that is hopefully more “real world” than the last article provided.
Try/catch blocks are certainly a nice feature to have. They allow you to catch errors that are beyond your control and handle them in a nice manner. They also allow you to throw your own errors and handle them in the same way. This would all be great if it weren’t for the fact that they are tremendously slow. Read on for some surprising test results.