null test versus try catch

Ask Time：2009-12-09T22:58:36 Author：mson

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?

Author:mson，eproduced under the CC 4.0 BY-SA copyright license with a link to the original source and this disclaimer.
Link to original article：https://stackoverflow.com/questions/1874433/null-test-versus-try-catch

Pieter888 :

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.",

2009-12-09T15:04:09

Charles Bretana :

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. ",

2009-12-09T15:17:28

philsquared :

Use exceptions for exceptional cases - not normal program flow.\n\nIf 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.\n\nI 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).",

2009-12-09T15:17:46

Justin Niessner :

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:\n\n// value is (Dude)Session[\"xxxx\"] if not null, otherwise it's a new object.\nDude x = (Dude)Session[\"xxxx\"] ?? new Dude();\n\n\nSave try/catch for Exceptions (truly unexpected events).",

2009-12-09T14:59:32

Mike Gleason jr Couturier :

If compact code is what you really looking for you can:\n\nDude x = Session[\"xxxx\"] as Dude ?? new Dude();\n\n\nthe ?? operator will return the first non-null value of two values if there is any.\n\nThanks",

2009-12-09T15:05:01

Powerlord :

I would think that this would be the fastest route:\n\nDude x = (Dude)Session[\"xxxx\"] ?? new Dude();\n\n\nThe ?? operator is a shortcut for null checking when you want to assign a specific value if it is null.\n\nAnyway, Exceptions end up not only creating a new object, but having the generate a stack trace, which slows things down.",

2009-12-09T15:03:40

Nathan Wheeler :

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.",

2009-12-09T15:01:47

Francis Upton IV :

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.",

2009-12-09T15:02:23

Benj :

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.",

2009-12-09T15:03:56

null test versus try catch