Some errors can be handled and some cannot. Nevertheless, it’s extremely common to see codebases chock-full of ineffective error handling for these unrecoverable issues. The result is a lot of extra code to write, maintain, and test that often serves to make debugging harder. Today’s article shows you how to make debugging internal errors so much easier by effectively writing code to handle them.
Posts Tagged exception
Unity 2018.1 was released last week and with it comes support for C# 6. Today we’ll take a look at the C++ that IL2CPP generates when we use the new features in C# 6. Warning: one of them is buggy and shouldn’t be used.
The story usually has three parts. First, find the highest CPU cost functions in a profiler. Second, look at the corresponding C++ code that IL2CPP generated from C#. Third, stop using more parts of C#. Today’s article explores some more IL2CPP output and discovers some more areas of C# that are shockingly expensive to use.
Like them or not, exceptions are the standard way of handling programming errors in C#. We need to be able to catch C# exceptions in our C++ code so we can gracefully recover from them. Likewise, we need uncaught C++ exceptions to behave like unhandled C# exceptions: display an error and move on instead of crashing. Today’s article continues the series by implementing both those features in the GitHub project and explaining how that implementation was done.
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!
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!