Does anyone have metrics on performing null test versus wrapping code in a try catch?
I suspect that the null test is much more efficient, but I don't have any empirical data.
The environment is C#/.net 3.x and the code comparison is:
Dude x = (Dude)Session["xxxx"];
x = x== null ? new Dude(): x;
versus
Dude x = null;
try {
x = (Dude)Session["xxxx"];
x.something();
} catch {
x = new Dude();
}
are there any advantages to wrapping in try catch?
If null is a possible expected value, then test for null. If you don't like the null test and have a default value, you can use the null coelescing operator to set the default value:
// value is (Dude)Session["xxxx"] if not null, otherwise it's a new object.
Dude x = (Dude)Session["xxxx"] ?? new Dude();
Save try/catch for Exceptions (truly unexpected events).
If compact code is what you really looking for you can:
Dude x = Session["xxxx"] as Dude ?? new Dude();
the ?? operator will return the first non-null value of two values if there is any.
Thanks
I would think that this would be the fastest route:
Dude x = (Dude)Session["xxxx"] ?? new Dude();
The ?? operator is a shortcut for null checking when you want to assign a specific value if it is null.
Anyway, Exceptions end up not only creating a new object, but having the generate a stack trace, which slows things down.
Exceptions do take extra memory, as well as time, to catch. It is ALWAYS better to test for null if it's a possible value.
Another thing to consider it that it's simply less code and more readable to do the null test. Usually having try/catch blocks adds essentially no overhead to your code for the normal case, but when the exception is triggered it's quite expensive.
I agree with @Justin Niessner. Furthermore you may want to read this article, which reveals some interesting points.
You should never use a try/catch in the normal code path of your program. If you do you'll create constant garbage which the garbage collector will need to process. Much better to just test for null.
Exception should work fine in this case, but I believe number #1 is the best way to go. An exception should not be used as an If/else statement, an exception throws an error, which takes up more system resources than your first comparison.
NEVER use exceptions for program control flow. The only time you would want to create an exception is if (Dude)Session["xxxx"]; being null was cause to stop the functioning of the method you were in. i.e., if a null value there would prevent that method from successfully accomplishing the function it was called to perform. As you wrote the question, if all you need to do in this case to continue is to create a new Dude(), then that is not the case, so an exception not warranted.
Use exceptions for exceptional cases - not normal program flow.
If you're having to do a lot of null checks consider making use of the Null Object Pattern instead of using real nulls to indicate a non-existent value that perhaps has default behaviour.
I was alway a bit suspicious of the Null Object Pattern until I started using Objective-C where it's the built-in behaviour. It really does clean up a lot of code (but it's still not always appropriate, of course).
As you only want to check for null, that is what you should do. It's more efficient than catching an exception.
Also, by catching exceptions you should be very specific and only catch exactly what you expect. If you catch any type of exception, you risk catching errors that you didn't anticipate and handle them the wrong way.
