Is it essential that I learn Try/Catch and Finally statements for Game Programming, or is it something I can come back to? [closed]

Question

Doesn't seem like something that would be an essential part of GAME Programming.

Answer 1

They are 100% essential. Do you want your game to crash any time an error happens? Granted, some errors will always cause a crash, but what about something as simple as network timeout? Wouldn't it be smarter to tell the player and have him try again, or check his network connection?

Picking them up is very easy.

try
{
    //open a network connection and try to get the leaderboard 
}
catch(Exception ex)  //type of exception, and a variable to access it by
{
    //tell the user something happend, and have them try again.
    //maybe you jut want to log it.

    LogError(ex);
    //so we have a record it happend, but the error was really bad! (out of memory) just throw it again if you need to
    throw;
}
finally
{
    //this happens no matter what. it will run on success and failure
}

Answer 2

While I agree with Joe's answer that exception handling is a useful skill to learn, it's my experience that they are rarely used in game development.

I'm not too sure on the differences in implementation, but in C++ the overhead involved with keeping stack traces to allow for effective unwinding whenever a 'throw' is encountered is pretty much the sole reason they're frowned upon.

This answer may provide you with more insight on the overheads involved with C# exception handling.

In terms of general program architecture, exceptions are not useful for determining the exact reasons for a crash, and make it troublesome to determine exactly where an error is occuring. You'll unwind to the point of the catch, but have little to no information (depending on usefulness of your exception) of where the error actually originated.

Answer 3

I would agree that it is something that you can come back to.

It is perhaps not essential to "game programming" in the ways that it can be to maintenance/support programming. In other words, if you can think of "game programming" as the discipline of crafting and delivering the game, then exception handling's benefits come to light after shipping out-the-door.

That said, there are things that can play a role in how soon:

• Your logging. So there will be a point when you start formulating a error management strategy. How early you form your strategy is directly related to the amount of support you incur from bug reports and captured log entries like "null reference". Often times, without the context that you can capture from the exception, you have to do more detective work and it is more difficult to group errors together, to see the similarities.

• Your patch system. If you can push out updates, then you have a lot of freedom to wait on doing exception handling. Same with if your logic is a web app and clients are just browsers.

• Your team size. If you are a one man team, then you have tremendous freedom to wait. You know your code. You may even know before hand that the exception was on your todo list. If you work and share code with other developers, you may be assigned a ticket to trace someone else's code so you may not immediately see where the exception is tripped.

• Concurrency. To me, this one is hard to plan for so it may not be worth the effort. Also, I feel this is part of robustness or resiliency. So if the requirements allow sudden crashes, then you have great freedom and so you'll wait to address exceptions. One thing you may find with threads is that it is easy to get non-deterministic behavior. When this happens, you want ways to capture as much information about the state leading up to the failure. This can include simulation in a lab of machines, regression tests, logs, (live) data. Individually each of these pieces can offset the the others to some degree. For example, if you have infinite tests you should be able to expose every logic failure and therefore not need exception handling (or logging or anything else).

Answer 4

Exception handling is a cleaner way to handle unexpected errors from any point in the game. But the beauty of it is, in your codebase, it won't matter how deep you are in the code to handle it. Without exceptions, some kind of error handling routine would be returning a bool or int for some kind of status, then unwinding the nested subroutines till you got to a top-level area (your game class) and exit from there. It will get very cumbersome to write your code to error check from any possible point, wheras using exceptions requires little to no refactoring.

Since your question is XNA specific, it will probably be of good use to know how to handle exceptions in an Xbox game, because when a game in there doesn't catch one, you are not left with a clue as to why it happened. This article shows you a clever way to work around that by running your entire game in a try/catch block. It will launch a new "ExceptionGame" if something happens to go wrong, passing the details of the error to display in the ExceptionGame.

Answer 5

No, exceptions aren't vital or essential in any way. For the most part traditional game programs are very heavy on error checks and knowing exactly what's going on with the data and parameters.

The exception to that is when accessing system calls, those will be throwing exceptions and how to catch them is very well documented and you can use the try/catch like a black box until you start to use exceptions more deeply on your own.

The whole try/catch thing is however very easy to pick up and once you get familiar with C# you will be able to see where exceptions make sense and you can start to add them into your own code naturally.

Assuming, of course, that you're just starting out. If you're learning C# after other languages then you should pick up exceptions and not wait until later.

Answer 6

I believe it depends on the nature of your game code. Are there areas in your flow of execution where things may fail? Is your code 100% handled? If the code has no way of failing, if you are aware of the post condition and certain of it, then exception handling is of little use, and would simply increase the use of resources to check for no reason. However, the majority of code does have situations where things may fail. Especially in game development, if a game is predictable, it would most likely lack the essence of being a game. Regardless of its use in game development, you MUST be aware of it and how to use it. But apply it where needed.

Answer 7

Do you want to know what went wrong in ur program without inserting breakpoints or looking at your entire code. If yes, then try-catch statements help you to do just that. It tells you what went wrong using preset types of errors. So by actually learning these statements and knowing what error stands for what, you can effectively debug your code without any hassle.

Answer 8

I don't know anything about C#, but here are my three cents:

1. The try/catch/finally exception handling paradigm is widespread, and for good reason: it provides an excellent framework for dealing with exceptions in your code.
2. If you're using a certain language, you should learn all its statements and how to use them or your code will be some combination of confusing, buggy, and inefficient. A lot of thought goes into the design of programming languages, and trying to write a program without using all the tools available to you is just... silly.
3. Not to be disparaging, but there are many challenging aspects of game development and trying to do it with the attitude of "I'm only going to learn what I absolutely need to get by" is not going to end well. You'd be better served using the journey to your goal of developing a game as an opportunity to learn as much as you possibly can.

Answer 9

Well,

Normally Object-Oriented software trend to use Exceptions for reporting errors in the running proccess. If something happens that the current method can't deal/resolve, it should throw an exception and let someone in the higher to treat this problem. If you do this way, your main processing methods (the more specific ones) will be much cleaner without the need to treat errors that it can't solve.

But normally, in game development Exceptions are not thrown because you are designing the hole enviorment. If you are designing your Engine, then yes, you'll use exceptions to basically I/O features, but in the scene, for example, it's not likely that you'll use it. I find out that it's better to try to add to a list of things that must be solve instead of throwing an error. For example, you have a client/server game. In the client, you noticed something that gone wrong. I find that it's better (for me) to add this error to a list of errors that must be solve, instead of breaking the sequence. That way, you could just jump this error and don't throw an exception, but someone will try to fix this problem.

But in any OO software you'll work with, remember that exceptions are always used. It's a really good thing to learn, very usefull and not hard at all.