Runtime asserts, not the asserts in unit tests, are a valuable debugging tool for any game developer. Today’s article shows you what they are, how to use them, how not to use them, and how they work. Read on to learn more!
Posts Tagged exception
Callbacks are a mainstay of the real-time games and apps we build in Unity. We’re constantly writing asynchronous code for every operation from walking a character to a destination to making a web call. It’s really convenient for these functions to “call back” and report their status so we know how the operation is going. Unfortunately there are also a lot of dangers that come along with this. Today we’ll look into the surprisingly large number of ways you can “call back” in C# and some of the ways you can get burned doing so.
Having just concluded the series on handling errors without using exceptions, now’s a good time to check up on an assertion I made in the first part: exceptions are slow. A good question to ask is “compared to what?” So let’s put them up against good old error codes and the new Either type I presented in the series. Which is fastest when there is no error? Which is fastest when there is an error? Read on to find out!
Last week’s article introduced the Either class as an alternative to exceptions that makes it easy for functions to declare their error results in addition to their success results and for callers of those functions to handle both results. Today we’ll go further by linking together multiple functions to handle all the error cases almost transparently. Read on to learn how to make the most out of Either!
Exceptions are the de facto way to handle errors in C#, but they have problems. Callers don’t know if the function they’re calling will throw an exception at all or which types of exceptions it’ll throw. Exceptions also introduce an alternative control flow that’s often hard for programmers to follow. They make our code slower too, even when never thrown! Today’s article introduces an alternative to exceptions to help solve all of these issues. Read on to learn a new way to handle errors!
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!
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.