Reputation: 8721
In my game, there are many things checked and often the indexes are out of bounds, and it's usually ok if sometimes things are not drawn or checked for. Currently my code is easy enough to read, though when debugging, the game loses a frame or two because of the exceptions that are being logged. It works fine outside the VS though. When I tried to avoid exceptional situations using lots and lots of if
statements, it greatly decreased code readability and removed the low fps loss. I wonder if it has any other effects.
Upvotes: 4
Views: 151
Reputation: 117144
You should always write your code to avoid exceptions. They are very costly to catch.
You should also avoid lots of nested if
statements. You're right, they make your code less readable.
You might find that switch
statements can help, but there are a number of other ways to avoid exceptions and if
statements.
For example, you could write this extension method:
public static class Ex
{
public static void IfBounded<T>(this T[] @this, int index, Action<T> action)
{
if (@this == null) throw new System.ArgumentNullException("@this");
if (action == null) throw new System.ArgumentNullException("action");
if (index >= @this.GetLowerBound(0) && index <= @this.GetUpperBound(0))
{
action(@this[index]);
}
}
}
Now you can write the following kind of code:
var messages = new []
{
"Hello",
"Goodbye",
};
messages.IfBounded(-1, t => Console.WriteLine(t));
messages.IfBounded(0, t => Console.WriteLine(t));
messages.IfBounded(1, t => Console.WriteLine(t));
messages.IfBounded(2, t => Console.WriteLine(t));
This particular extension method may not be suitable for your situation, but something like this can make your code quite succinct and terse.
Upvotes: 0
Reputation: 311645
Is it ok to use lots of
try
s instead of even moreif
s?
If you need either of these to have a functional application, then something may be wrong with your design. Exceptional situations are generally supposed to be exceptional, not commonplace.
The situations you described (indices out of bounds) are clearly not exceptional, especially since you ignore the exceptions because it's not a big deal. That's a big hint that you should be investing the effort into preventing the exceptions from happening in the first place.
When I tried to avoid exceptional situations using lots and lots of if statements ...
Lots of if
statements is not a good approach, as you discovered -- it's hard to read, and it may hide logic errors, which just creates more headaches.
Instead, consider giving your objects more clearly defined and discrete responsibilities, to prevent them from entering states that might be exceptional to begin with. If you need "lots and lots" of if
statements, then your objects are checking many conditions, which means their responsibilities are probably too big.
Upvotes: 4
Reputation: 4965
In general, you should write your code and structure your logic so that exceptions are not used to process program logic. In some circumstances, it is okay to use exceptions to deal with conditions that are rare but expected. However, exceptions should be avoided for control flow because they are basically goto
statements that can make control flow very confusing, and they are not performant.
In your case, it does not sound like using exceptions for handling logic errors is appropriate. In fact, the exceptions sound like they are doing precisely what they were meant to do. That is, they are telling you that your algorithm is wrong.
I would recommend looking at your code carefully, and determining why your code throws IndexOutOfBoundsException
. If it's being thrown during internal processing of your own parameters, you've probably got a bug or a poorly designed algorithm. Ask, "where did this index come from?" and "Is there a way to write the algorithm so that bounds are built into the design and not tacked on as an afterthought?"
Upvotes: 2
Reputation: 51369
Throwing exceptions is very resource intensive- it is vastly faster to use if/then statements or other "normal" flow control.
Exceptions are mainly expensive because generating the Exception instance requires a stack walk has to be performed to figure out where the exception was thrown (the stack trace). It also creates extra load for the Garbage Collector, and is considered very poor design to use exceptions outside of exceptional situations.
Upvotes: 7