Error handling techniques for nested methods that can throw exceptions I have 2 different approaches I'm using to handle error state or Exceptions from within nested functions.  Take the following code for example:

public void Func1()
{
    try
    {
        Func2(); 
        //... continued logic if no exception was encountered 
    }
    catch (Exception ex)
    {
        log(ex.Message);
        return;
    }

}

public void Func2()
{
    try
    {
        Func3();
    }
    catch (Exception ex)
    {
        log(ex.Message);
        throw;
    }
}


In the above sample, Func1 needs to know if Func2 (and other methods Func2 calls) have thrown an exception, so that it can continue with execution.  This appears to me to be an obvious code-smell and it's something I'd like to avoid doing.  Here's the next option I've tried:

public void Func1()
{
    try
    {
        bool success = Func2();
        if (!success)
        {
            //... continued logic if no exception was encountered
        }
    }
    catch (Exception ex)
    {
        log(ex.Message);
        return;
    }
}

public bool Func2()
{
    try
    {
        bool success = Func3();
        if (!success) return false;
        return true;
    }
    catch (Exception ex)
    {
        log(ex.Message);
        return false;
    }
}


Using this second method, the nested functions return a boolean to determine state and whether or not the calling function should continue.  This also doesn't feel right to me.  I'd really like suggestions on ways to handle situations like this where I'm calling nested functions (particularly when they return void because they do unrelated processing to the class).  Thanks!

EDIT: updated from pseudo-code to valid C#.
If shortly, using exceptions is not a code-smell.



In my opinion using bool return values is appropriate for methods that are purposed for checking some conditions. Examples:

bool CanFunc2BeCalled() {  ... }
bool TryParse(string s, out ... value) { ... }


Such methods specifically designed to return bool. It is the main job they do.

If a method should perform some actions and during its execution an exception can be occured I would not return bool to indicate a failure. An exception is the right choice for these cases.

Exceptions is a native conception of .NET so don't be afraid of them :) Also with good XML comment on methods you always know what exceptions the method can throw:

///&lt;summary&gt;
///...
///&lt;/summary&gt;
///&lt;exception cref="InvalidOperationException"&gt;Description of failure.&lt;/exception&gt;
void Func2() { ... }


So if you are able to check that call of a method can cause an exception before its execution, create the method for checking some conditions and call it before:

private bool CanFunc2BeCalled() {  ... }

public void Func1()
{
    if (!CanFunc2BeCalled())
        return;

    Func2();    
}


But if you can't check if the Func2 can be safely called before its execution then dealing with exceptions is a good way and I would stick with it.