¿Qué sucede si un bloque finalmente lanza una excepción?

Para preguntas como estas generalmente abro un proyecto de aplicación de consola vacío en Visual Studio y escribo un pequeño programa de ejemplo:

using System;

class Program
{
    static void Main(string[] args)
    {
        try
        {
            try
            {
                throw new Exception("exception thrown from try block");
            }
            catch (Exception ex)
            {
                Console.WriteLine("Inner catch block handling {0}.", ex.Message);
                throw;
            }
            finally
            {
                Console.WriteLine("Inner finally block");
                throw new Exception("exception thrown from finally block");
                Console.WriteLine("This line is never reached");
            }
        }
        catch (Exception ex)
        {
            Console.WriteLine("Outer catch block handling {0}.", ex.Message);
        }
        finally
        {
            Console.WriteLine("Outer finally block");
        }
    }
}

Cuando ejecute el programa verá el orden exacto en el que se ejecutan los bloques catch y finally. Tenga en cuenta que el código en el bloque finally después de lanzar la excepción no se ejecutará (de hecho, en este programa de ejemplo, Visual Studio incluso le advertirá que ha detectado código inalcanzable):

Inner catch block handling exception thrown from try block.
Inner finally block
Outer catch block handling exception thrown from finally block.
Outer finally block

Adicional Observación

Como Michael Damatov señaló, una excepción del bloque try se "comerá" si no la manejas en un bloque (interior) catch. De hecho, en el ejemplo anterior, la excepción re-lanzada no aparece en el bloque catch externo. Para hacerlo aún más claro, mira la siguiente muestra ligeramente modificada:

using System;

class Program
{
    static void Main(string[] args)
    {
        try
        {
            try
            {
                throw new Exception("exception thrown from try block");
            }
            finally
            {
                Console.WriteLine("Inner finally block");
                throw new Exception("exception thrown from finally block");
                Console.WriteLine("This line is never reached");
            }
        }
        catch (Exception ex)
        {
            Console.WriteLine("Outer catch block handling {0}.", ex.Message);
        }
        finally
        {
            Console.WriteLine("Outer finally block");
        }
    }
}

Como puede ver en la salida, la excepción interna es "perdida" (es decir, ignorada):

Inner finally block
Outer catch block handling exception thrown from finally block.
Outer finally block

Si hay una excepción pendiente (cuando el bloque try tiene un finally pero no catch), la nueva excepción reemplaza a esa.

Si no hay ninguna excepción pendiente, funciona como lanzar una excepción fuera del bloque finally.

La excepción se propaga.

Fragmento rápido (y bastante obvio) para guardar "excepción original" (lanzado en el bloque try) y sacrificar "finalmente excepción" (lanzado en el bloque finally), en caso de que el original sea más importante para usted:

try
{
    throw new Exception("Original Exception");
}
finally
{
    try
    {
        throw new Exception("Finally Exception");
    }
    catch
    { }
}

Cuando se ejecuta el código anterior, "Excepción Original" propaga la pila de llamadas, y "Finalmente Excepción" se pierde.

Tuve que hacer esto para detectar un error al intentar cerrar una transmisión que nunca se abrió debido a una excepción.

errorMessage = string.Empty;

try
{
    byte[] requestBytes = System.Text.Encoding.ASCII.GetBytes(xmlFileContent);

    webRequest = WebRequest.Create(url);
    webRequest.Method = "POST";
    webRequest.ContentType = "text/xml;charset=utf-8";
    webRequest.ContentLength = requestBytes.Length;

    //send the request
    using (var sw = webRequest.GetRequestStream()) 
    {
        sw.Write(requestBytes, 0, requestBytes.Length);
    }

    //get the response
    webResponse = webRequest.GetResponse();
    using (var sr = new StreamReader(webResponse.GetResponseStream()))
    {
        returnVal = sr.ReadToEnd();
        sr.Close();
    }
}
catch (Exception ex)
{
    errorMessage = ex.ToString();
}
finally
{
    try
    {
        if (webRequest.GetRequestStream() != null)
            webRequest.GetRequestStream().Close();
        if (webResponse.GetResponseStream() != null)
            webResponse.GetResponseStream().Close();
    }
    catch (Exception exw)
    {
        errorMessage = exw.ToString();
    }
}

Si se creó la WebRequest pero ocurrió un error de conexión durante el

using (var sw = webRequest.GetRequestStream())

Entonces, finalmente, atraparía una excepción tratando de cerrar conexiones que pensaba que estaba abierta porque se había creado la WebRequest.

Si finalmente no tenía un try-catch dentro, este código causaría una excepción no controlada mientras limpiaba el WebRequest

if (webRequest.GetRequestStream() != null) 

A partir de ahí, el código saldría sin manejar correctamente el error que ocurrió y, por lo tanto, causando problemas para el método que llama.

Espero que esto sirva de ejemplo

Lanzar una excepción mientras otra excepción está activa dará lugar a que la primera excepción sea reemplazada por la segunda excepción (posterior).

Aquí hay un código que ilustra lo que sucede:

    public static void Main(string[] args)
    {
        try
        {
            try
            {
                throw new Exception("first exception");
            }
            finally
            {
                //try
                {
                    throw new Exception("second exception");
                }
                //catch (Exception)
                {
                    //throw;
                }
            }
        }
        catch (Exception e)
        {
            Console.WriteLine(e);
        }
    }

• Ejecute el código y verá "segunda excepción"
• Descomente las declaraciones try and catch y verá "primera excepción"
• También descomente la declaración throw; y verá "segunda excepción" de nuevo.

Hace algunos meses también me enfrenté a algo como esto,

    private  void RaiseException(String errorMessage)
    {
        throw new Exception(errorMessage);
    }

    private  void DoTaskForFinally()
    {
        RaiseException("Error for finally");
    }

    private  void DoTaskForCatch()
    {
        RaiseException("Error for catch");
    }

    private  void DoTaskForTry()
    {
        RaiseException("Error for try");
    }


        try
        {
            /*lacks the exception*/
            DoTaskForTry();
        }
        catch (Exception exception)
        {
            /*lacks the exception*/
            DoTaskForCatch();
        }
        finally
        {
            /*the result exception*/
            DoTaskForFinally();
        }

Para resolver este problema hice una clase de utilidad como

class ProcessHandler : Exception
{
    private enum ProcessType
    {
        Try,
        Catch,
        Finally,
    }

    private Boolean _hasException;
    private Boolean _hasTryException;
    private Boolean _hasCatchException;
    private Boolean _hasFinnallyException;

    public Boolean HasException { get { return _hasException; } }
    public Boolean HasTryException { get { return _hasTryException; } }
    public Boolean HasCatchException { get { return _hasCatchException; } }
    public Boolean HasFinnallyException { get { return _hasFinnallyException; } }
    public Dictionary<String, Exception> Exceptions { get; private set; } 

    public readonly Action TryAction;
    public readonly Action CatchAction;
    public readonly Action FinallyAction;

    public ProcessHandler(Action tryAction = null, Action catchAction = null, Action finallyAction = null)
    {

        TryAction = tryAction;
        CatchAction = catchAction;
        FinallyAction = finallyAction;

        _hasException = false;
        _hasTryException = false;
        _hasCatchException = false;
        _hasFinnallyException = false;
        Exceptions = new Dictionary<string, Exception>();
    }


    private void Invoke(Action action, ref Boolean isError, ProcessType processType)
    {
        try
        {
            action.Invoke();
        }
        catch (Exception exception)
        {
            _hasException = true;
            isError = true;
            Exceptions.Add(processType.ToString(), exception);
        }
    }

    private void InvokeTryAction()
    {
        if (TryAction == null)
        {
            return;
        }
        Invoke(TryAction, ref _hasTryException, ProcessType.Try);
    }

    private void InvokeCatchAction()
    {
        if (CatchAction == null)
        {
            return;
        }
        Invoke(TryAction, ref _hasCatchException, ProcessType.Catch);
    }

    private void InvokeFinallyAction()
    {
        if (FinallyAction == null)
        {
            return;
        }
        Invoke(TryAction, ref _hasFinnallyException, ProcessType.Finally);
    }

    public void InvokeActions()
    {
        InvokeTryAction();
        if (HasTryException)
        {
            InvokeCatchAction();
        }
        InvokeFinallyAction();

        if (HasException)
        {
            throw this;
        }
    }
}

Y usado así

try
{
    ProcessHandler handler = new ProcessHandler(DoTaskForTry, DoTaskForCatch, DoTaskForFinally);
    handler.InvokeActions();
}
catch (Exception exception)
{
    var processError = exception as ProcessHandler;
    /*this exception contains all exceptions*/
    throw new Exception("Error to Process Actions", exception);
}

Pero si quieres usar parametros y tipos de retorno eso es otra historia

public void MyMethod()
{
   try
   {
   }
   catch{}
   finally
   {
      CodeA
   }
   CodeB
}

La forma en que se manejan las excepciones lanzadas por CodeA y CodeB es la misma.

Una excepción lanzada en un bloque finally no tiene nada especial, trátela como la excepción lanzada por el código B.

La excepción se propaga hacia arriba, y debe manejarse a un nivel superior. Si la excepción no se maneja en el nivel superior, la aplicación se bloquea. La ejecución del bloque" finally " se detiene en el punto donde se lanza la excepción.

Independientemente de si hay una excepción o no se garantiza la ejecución del bloque "finally".

1. Si el bloque" finally " se está ejecutando después de que se haya producido una excepción en el bloque try,

2. Y si esa excepción no se manipula

3. Y si el bloque finalmente lanza una excepción

Entonces la excepción original que ocurrió en el bloque try se pierde.

public class Exception
{
    public static void Main()
    {
        try
        {
            SomeMethod();
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex.Message);
        }
    }

    public static void SomeMethod()
    {
        try
        {
            // This exception will be lost
            throw new Exception("Exception in try block");
        }
        finally
        {
            throw new Exception("Exception in finally block");
        }
    }
} 

Gran artículo para detalles

Lanza una excepción ;) Puede capturar esa excepción en alguna otra cláusula catch.