Exceptions vs "if" in C#

Question

I have a control flow question. In my company we create a lot of bool methods that return false if there was an error. Example:

public bool Foo(string path, string fileName, ref string error)
{
    if (path == null)
    {
        error = "path is null";
        return false;
    }
    path += fileName;
    return true;
}

As you can see it's ugly. I want to use it with exceptions like so:

public voidFoo(string path, string fileName, ref string error)
{
    if (path == null)
    {
        throw new SomeException("Path is null.");
    }
    path += fileName;
    return true;
}

But we worry about the overhead. Should we?

What you really want is to remove the ugly `error` parameter in the second example. — Doc Brown, Jan 23 '11 at 12:06
Folks, do we really need so many answers that say exactly the same thing? — Cody Gray - on strike, Jan 23 '11 at 14:13
Zero overhead if you ensure `path` is not `null` before calling `voidFoo`. — Lightman, Aug 21 '16 at 08:49

score 3 · Accepted Answer · answered Jan 23 '11 at 12:00

If the exception is not thrown, then the overhead of your try...catch is negligable. So, the rule of thumb is:

If the exception is likely to be thrown (i.e., if path == null is a "supported" scenario), use the return value.
If the exception is unlikely, i.e., if path == null usually only happens if the developer using your function makes a mistake, then use an exception.

score 2 · Answer 2 · answered Jan 23 '11 at 11:58

You should never use exceptions as a form of flow control.

In general, throwing exceptions is much more expensive than checking for a fail value - in this case, if path should never be false and is expected to always exist, an empty path is an exceptional situation and an exception should be thrown.

In term of method design - you shouldn't rely on the calling method to check a return value. If someone forgets to check, what will happen if a false is returned? An exception makes this issue go away, as something bad clearly happened and your code stops running.

You mean: one should never use exceptions as a form of *regular* flow control. — Doc Brown, Jan 23 '11 at 12:07

score 1 · Answer 3 · edited Jul 31 '11 at 13:16

How exceptional is this occurrence? Throwing and catching exceptions will incur an overhead that you may not be willing to take in general usage.

Stylistically, using exceptions for flow control is frowned upon, both for performance and comprehension reasons. I would use exceptions if this is (no pun) an exceptional occurrence. If performance is key (and you should measure this - premature optimisation being the root of all evil, etc.) then a more optimal solution would be to use the return value.

The headache with such scenarios is that it's possible to ignore or misuse the return value (being false or null, usually).

score 1 · Answer 4 · answered Jan 23 '11 at 12:02

Exceptions should be reserved for exceptional cases such as a resource is unavailable E.g. disk space or a network connection.

Using exceptions for flow control is simply wrong, it doesn't smell right.

Using a boolean return code is one way. You could also create an error object that describes the cause of the error rather than returning via a ref.

score 0 · Answer 5 · answered Jan 23 '11 at 11:58

All books say that you should use exceptions for signalling errors. If you use if's then 50% of your source lines are about return error messages and it is hard to read the source and see whether it's bugless.

Use return values only in time critical scenarios where you expect many errors to occur and computational time is very important for you.

score 0 · Answer 6 · answered Jan 23 '11 at 11:59

I love exceptions. I just do. Of course it depends on where you are implementing.

For example, I would like to have some very basic classes to just throw an exception, because I don't want these classes to have the responsibility of not throwing it.

Nice thing of C# is that you don't have to catch every exception, because it just throws it further if it goes wrong. So that will save you a lot of code. Else with booleans it would be: if false -> return false; if false -> return false;. I think that would be overhead.

Of course at some point, you have to catch your exception, but that is of the choice of the implementer where to do it. You don't want some giant catch block of course, but only at the point where you want to catch it, you should catch it.

I'd go for it.

score 0 · Answer 7 · answered Jan 23 '11 at 12:03

It depends on whether what you consider the "false" state to be exceptional or not. Or in other words not generally expected.

For example, if you pass in an object to a method that does not make any sense if it is null for the method to do its work, then perhaps you should be throwing an ArgumentNullException:

public void Foo(object obj)
{
    if(obj == null) throw new ArgumentNullException("obj", "Object cannot be null.");

    //
}

Exceptions vs "if" in C#

7 Answers7

Linked