Unity code frequently makes use of the coroutine feature of MonoBehaviour. It can make asynchronous code a lot easier to write, but runs into problems when exceptions are thrown. There’s no avoiding exceptions since they’re built into C# (e.g. NullReferenceException) but we can cope with them, even when they’re in coroutines. Today’s article introduces a helper function or two that you can drop into your projects to help you handle exceptions thrown from your coroutines. Read on to learn how!
Posts Tagged exception
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!
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.