Error Handling

I talk about how I handle error handling in the code of my games.

Videos I reference:

[souluss]

These software oriented vids are fantastic, thank you.

[aNerdNamedJames]

Genuinely appreciate being a narrative design person watching this and going "oh, okay, I know some of these words".

[WhereTheFriesAt]

I'm officially in my first week of crash-coursing programming, and videos like these were a huge push in getting me started. You've ignited a genuine fire for game dev in me, Tim. I have always enjoyed flavoring up my TTRPGs with custom rules or systems, and I have always had lots of "I'll do it later" ideas for designing games. I forget which video, but you were referring to credits, and whether the idea or the work that made the idea real matters more, and it really changed the way I look and think about it. Thanks for getting me to actually try!

[ComradeStrogg]

13:47 — Tim passed the skill check and avoided dropping the F bomb

[lfarrocodev]

The get/set tip for change monitoring is quite useful

[View]

From a fellow engineer (and Tim), it's always interesting to hear your perspective Tim!

[RHD]

I have no idea what you're talking about, I just play the games and code is foreign to me, but I adore you and love to hear you talk about this stuff!

Thanks for sharing, Tim!

[spudd]

C++ has a very nice solition to the lock with no unlock problem, you just make the lock return a very very simple class that basically implements the derefernve operator to pass through to a pointer it holds, then it unlocks in it's destructor it has two pointers inside it, or even just one depending on how your handles work, the locked pointer and a pointer to the handle. You make it noncopyable, but moveable. So you just have locking look like "auto ptr = handle.lock();" and it will just deal with early exits for you. Make all it's members inline, mark it as final (yay c++ 11), no virtual destructor. Everything will get inlined and probably even the extra copy of the pointer/reference to the handle will go away. Compiler optimisations are pretty reliable as long as you stick to -O2 on gcc/clang and you understand the strict aliasing rules. Or you can turn off strict aliasing. Most programmers are wrong about when a compiler is allowed to assume two things don't ever have the same address.

[MudHoleCreation]

Thank you Tim, for reading our comments and answering our questions. I feel it may one day be too much for you to handle. I feel lucky that I was able to ask one before that time. I get so much value out of your videos.

[Nick-jbjn]

Hey Tim, just found your channel recently and have been obsessed. I’m a software engineer myself but not a game developer so always interesting to hear your dev stories and technical talks. Thank you for all that you do, you are appreciated!

[anima]

I like the slight pause after reading the name 0:10

[fredericbrown]

I have the impression that error handling is one area where when you're programming for a video game you tend to have different considerations than when you're working on a business software or a tool. When doing the later, you do want to protect the integrity of your data, etc. and will usually want to abort when an abnormal state is detected while I guess that in a video game it might be preferable to think along the lines of "the show must go on". 4:42 I would agree with all those academics that avoiding global variables, and (especially mutable) global state in general, is good advice: it makes it possible to think about the behavior of a class or method in isolation when you're not referring to data other then the one passed in parameters (or encapsulated in the same class). That said, like pretty much everything in programming, it always depends (of your language features, hardware restrictions, performance requirements, etc.) and that's why it's always interesting to hear from an experienced programmer.

[vk]

For Tim’s videos YouTube is always showing me chocolate ads.

There is a term I've always used to describe the type of subsequent cascading yet irrelevant issues that get reported after continuing past a root cause bug (besides calling them ghosts) -- they're artifacts! Context is key.

Love these talks; even though I will likely always feel like I have no idea what I'm doing, hearing you echo many of the same viewpoints I've collected over my development career really makes me feel way less imposter syndrome.

[JavierBonnemaison]

I really appreciate your insights about performance. A lot of people work on native and web apps these days, and performance tends to take a back seat for many developers.

[JavierBonnemaison]

The choice between halting or continuing after an error can be more nuanced. The way I would have handled it is to issue the error message but continue to run the program, and then implement different policies for different roles. For example, a developer that sees an error message would be expected to stop and fix (in TPS/Lean terms it would be pulling the Andon cord), while a tester or someone working on content would have the choice to ignore it and continue. Blocking people is always problematic, but people with different roles or goals don't necessarily have to react to events in the same way. The easiest way to manage this is to model workflows by role and work type, and use fast and frugal decision trees to allow individuals to decide the best course of action on their own depending on context (basically if then chains for people rather than machines).

[TheSequentCalculus]

The thing with globals is that they make it really hard to prove correctness. You can in principle pull state through every function and make writes atomic, which resolves much of the issue but is really cumbersome to write. Or you can program a "sliceable" set and only pass those globals into objects or functions that are needed there, rather than allowing access to just *everything*. For error handling, I've gravitated towards simplified monads. In C++23, they've provided std::expected, but I haven't looked into that yet. It's even possible to use a std::expected-like interface, but vary the implementation. In development, you can interrupt and halt (allowing you to attach a debugger), in testing you can produce an error and a stack trace, or (if you are in the "continue if at all possible"-camp) a default value, and for production you can just exit and print an error message.

[aerisdiesattheendofdiscone]

you can never make everyone happy, but you can always make everyone mad.

[rustinpeace]

I work with Java in an insurance company. Interesting to hear the perspective of an expert from another programming field on this subject.

[greenya]

Thank you for great video, as always. Just my 2 cents --
About the decision to "print a message and halt or continue". I think its all depends. But here are some things i tend to keep in mind:
- always write to log file (you can print message to user, but that message and all others should be in log)
- when submitting bug, always require attached log file (if log file is only generated for debug builds, tester should play on debug build most of the time; test release build separately)
- to stop or to halt? it depends:
- if you cannot load a game level, you halt
- if you cannot load a texture, you show it as some "not found" one (like checker), yes, it can be unnoticed by the tester, but you still write a warning message in the log about it
- basically, warnings are treated as something that should not happen, e.g. kind of error after which we can continue, and warning should be fixed later