Error Handling
Understanding the importance of error handling

Like what your seeing?

Consider supporting us as a GitHub Sponsor and get instant access to all our Unity assets, exclusive tools and assets, escalated support and issue tracking and our gratitude. These articles are made possible by our GitHub Sponsors ... become a sponsor today!


Error handling refers to the practice of detecting errors in your processes, states and systems, and handling those conditions in a graceful manner. Ideally your game would "recover" from error states but worst case it should gracefully shut down as opposed to the blind crash to desktop.
This section will cover some basic concepts of error handling as they apply to Unity game development, and will highlight areas the UX toolkit can help deliver a better user experience.

Learning First

While there are many "code free" tools to help prototype, and many would claim fully create a game with no programming required, you and your users will benefit greatly from a basic level of programming skill. In particular this will be important to achieve a level of quality in terms of your user experience in particular around error handling, recovery and reporting.
Learning the basics shouldn't be scary at all, and in our opinion can often be done faster and to a higher degree of mastery easier; than the effort involved in learning many of the "Visual Programming" tools. At the end of the day you probably already know how to type, so you already know more about programming than you do about some visual scripting tool since creating code is just literally typing words.
Junior Programmer - Unity Learn
Unity Learn
Unity Learn is a site provided by Unity that helps teach various skills around Unity game development, and the Junior Programmer path is a great starting place for absolutely anyone who will be using Unity at all.


Once your a few hours into Unity's Junior Programmer course, or if your already quite comfortable with scripting in Unity, check out these quick programming tips; they will help you a ton when thinking about error handling.

ALWAYS use a namespace

Without exception always define all of your code in a properly formed namespace
One major issue with learning to program through Unity, is that Unity is absolutely horrible with how it handles its coding style in particular around common conventions like namespace.
Namespaces - Unity Learn
Unity Learn
Strangely Unity considers the use of namespaces as an "intermediate" concept, and only references it as import for code organization. However, this couldn't be further from the truth. Properly formed code is more than just about organizing your class objects, it helps reduce the risk of ambiguity which can result in bugs that don't through errors and can be incredibly difficult to track down even for a skilled engineer.
This topic bares more attention than we will give it here, so just accept that ALWAYS using a namespace in ALL of your code is an absolute must.

What can go wrong, will go wrong

This is a very true statement with any software, anything really but especially software. If you have some logic that can break, it will break so handle that. C# gives you various tools and one of the easiest to use is the try catch block
//Some code that could thrown an exception
catch(ExceptionType ex)
//What to do when it does throw an exception
try-catch - C# Reference
You can find numerous video tutorials on YouTube, many of which dealing specifically with Unity and try/catch error handling.

Dev Time > Run Time

If it can be done at dev time, it is better than doing it at run time. This means if you can do it as a configuration that is saved at development time in the editor, as opposed to it being a process that calculates at run time, that is literally more performant in that process at run time consume processor time. Configurations need to be loaded but that is (most likely) always faster than calculating.
Unity's examples very often do something like this
public class SomeExample : MonoBehaviour
private MeshRenderer meshRenderer;
void Start()
meshRenderer = GetComponenet<MeshRenderer>();
Just don't. This is a process that happens at run time, you are telling the system to search list of components on this GameObject, and return the first occurrence that is or was derived from the MeshRenderer type. This consumes time and increases the possibility of run time errors.
The better answer is to do this at dev time
public class SomeExample : MonoBehaviour
private MeshRenderer meshRenderer;
Now in the Unity inspector you can drag and drop the desired MeshRenderer into this slot. You know at dev time that it is populated, you know what its populated with and at run time no processing need occur.
So why does Unity's examples show the GetComponenet approach?
We don't know, but assume it's so you don't have the step of dragging and dropping the reference. This means the code example is self contained and doesn't require extra explanation around the use of the inspector. This is just an assumption.
For note using the "transform" member of a mono behaviour is the same as calling GetComponenet<Transform>() and so takes processing time.
If you will need the transport more than once then reference it e.g.
private Transform selfTransform;
Now you can reference it at dev time and its always available to you
HeathenBehaviour a tool in System Core does this for you