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

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

## closed as not constructive by TetradFeb 28 '12 at 6:26

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

• Actually, it is essential that you learn ALL statements. It's not like there are some parts of the language that are "optional". – Nevermind Sep 28 '11 at 8:17
• And regarding game programming, try/catch/finally is far from the hardest thing you'll have to tackle. – Jari Komppa Sep 28 '11 at 8:25
• This isn't a good kind of question: gamedev.stackexchange.com/faq#dontask. Is there actually a problem to be solved here? – Tetrad Sep 28 '11 at 14:34
• There's a C# and XNA tag in there - then it's absolutely essential. Heck, if you ever go XBLIG you'll have to deal with dozens of (well-documented) exceptions just for the standard Xbox Live handling, if nothing else... – Oskar Duveborn Sep 28 '11 at 18:07
• @Jari: There's an immense difference between the question "When and how should I use exceptions?" and "Do I need to learn what exception keywords do?" – user744 Sep 28 '11 at 19:28

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
}

• let me rephrase his answer you need to learn how to use try/catch/finally and use them but there is no need to learn about throw. – Ali1S232 Sep 28 '11 at 7:37
• Actually the finally part will not run everytime, see stackoverflow.com/questions/4193493/finally-block-not-running – UrbanEsc Sep 28 '11 at 10:20

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.

• In c++ you are right, throw and catch are not really used, but in c# it's a different story, even casting will throw if something goes wrong! – Ali1S232 Sep 28 '11 at 7:35
• I strongly disagree, network sessions, storage (saves), setting up the render device, all these kind of elementary things will often throw exceptions and the users expects you to handle this properly. – Roy T. Sep 28 '11 at 9:55
• Gajet : As C# is much less used for 'proper' game development, that's another problem :P @Roy T. I've never personally used any sort of game programming framework that uses exceptions to inform the programmer of an error, only ones that return error codes or leave you with a NULL pointer. – Jonathan Connell Sep 28 '11 at 17:09
• @JonathanConnell I think that is a very old fashioned view. The whole idea of exceptions is that error checking becomes easier, simpler and that you can't forget important errors. It reduces the amount of seriously hard to debug errors by adhering to 'fail early' and an amount of boiler-plate if statements that could be done with a few try-catches, since most places that can fail (mainly IO) are close together. I do see/agree that functions in the standard game loop do not throw exceptions often, but simply because they can't fail. Exceptions mainly occur in IO and networking parts of a game. – Roy T. Sep 28 '11 at 20:44
• Als in C# exception handling is basically free (see the second answer here stackoverflow.com/questions/52312/… ) generating exceptions is expensive though, but that's ok since it should only happen in exceptional situations. If you're generating 1000 exceptions per frame then something is seriously wrong. – Roy T. Sep 28 '11 at 20:51

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).

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.

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.

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.

• No, exceptions ARE vital in a very important way. Understanding and using try-catch-throw can easily cut your debugging time ten-fold. – Nevermind Sep 28 '11 at 8:18
• Exceptions might be optional if we were talking c++, but not c#. – Jari Komppa Sep 28 '11 at 8:25
• I've got to disagree. Solid game programs existed long before exceptions and continue to exist without them to this day, complex games that are vetted for 48 hour continuous running times by major publishers and not just little toy titles. If you're arguing that exceptions should be an essential part of the logic running the game then I think you might either be misusing exceptions or forgetting about assert, which is indeed a vital debugging tool. – Patrick Hughes Sep 28 '11 at 15:37
• @Patrick Hughes You can write a "solid game program" without using anything except base x86 assembler. It doesn't mean you should. If we're talking about C#, exceptions are an essential and very important part of the language. (Assertions, OTOH, are not part of the language at all, although I can't dispute their usefulness) – Nevermind Sep 28 '11 at 16:06
• I bow to the collective wisdom of these forums! I won't edit my answer but instead will leave it behind as a reminder to not do that, and follow the best answer(s) myself above should I ever dive deeper into C# =) – Patrick Hughes Sep 28 '11 at 22:47

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.

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.

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.