Catch block is not being evaluated when exceptions are thrown from finallys

This question came about because code that worked previously in .NET 4.0 failed with an unhandled exception in .NET 4.5, partly because of try/finallys. If you want details, read more at Microsoft connect. I used it as the base for this example, so it might be helpful to reference. The code For the people who chose to not read about the details behind this question, here is a very quick look at the conditions where this happened: ``` using(var ms = new MemoryStream(encryptedData)) using(var cryptoStream = new CryptoStream(encryptedData, decryptor, CryptoStreamMode.Read)) using(var sr = new StreamReader(cryptoStream)) ``` This issue is that there are exceptions thrown from the `Dispose` method of CryptoStream (since they are inside a using statement, these exceptions happen to be thrown from two different finally blocks). When `cryptoStream.Dispose()` is called by the `StreamReader`, the `CryptographicException` is thrown. The second time `cryptoStream.Dispose()` is called, in its using statement, it throws a `ArgumentNullException` The following code removes most of the unnecessary code from the link provided above, and unwinds the using statements into try/finallys to clearly show that they are being throw in finally blocks. ``` using System; using System.Security.Cryptography; namespace Sandbox { public class Program { public static void Main(string[] args) { try { try { try { Console.WriteLine("Propagate, my children"); } finally { // F1 Console.WriteLine("Throwing CryptographicExecption"); throw new CryptographicException(); } } finally { // F2 Console.WriteLine("Throwing ArgumentException"); throw new ArgumentException(); } } catch (ArgumentException) { // C1 Console.WriteLine("Caught ArgumentException"); } // Same behavior if this was in an enclosing try/catch catch (CryptographicException) { // C2 Console.WriteLine("Caught CryptographicException"); } Console.WriteLine("Made it out of the exception minefield"); } }} ``` Note: The try/finally correspond to expanded using statements from the referenced code. Output: ``` Propagate, my children Throwing CryptographicExecption Throwing ArgumentException Caught ArgumentException Press any key to continue . . . ``` It doesn't appear that the `CryptographicException` catch block is ever executed. However, removing that catch block causes the exception to terminate the runtime. A little more information EDIT: This was updated to the newest revision of the specification. The one I happened to grab off of MSDN had older wording. `Lost` has been updated to `terminated`. Diving into the C# spec, sections 8.9.5 and 8.10 discuss exception behavior: - When an exception is thrown, including from inside a finally block, control is transferred to the first catch clause in an enclosing try statement. This continues up try statements until a suitable one is found. - If an exception is thrown during execution of a finally block, and an exception was already being propagated, that exception is terminated "Terminated" makes it seem that the first exception would forever be hidden by the second thrown exception, though it doesn't seem to be what is happening. I'm sure the question is in here somewhere For the most part, it's easy to visualize what the runtime is doing. The code executes to the first finally block (`F1`) where an exception is thrown. As the exception propagates, the second exception is thrown from the second finally block (`F2`). According to the spec, the `CryptographicException` thrown from `F1` is now terminated, and the runtime is looking for a handler for the `ArgumentException`. The runtime finds a handler, and executes the code in the catch block for the `ArgumentException` (`C1`). Here is where it gets foggy: the spec says that the first exception would be terminated. However, if the second catch block (`C2`) is removed from the code, the `CryptographicException` that was supposedly lost, is now an unhandled exception that terminates the program. With the `C2` present, the code will not terminate from an unhandled exception, so on the surface it appears to be handling the exception, but the actually exception handling code in the block is never executed. Questions The questions are basically the same, but re-worded for specificity. How is it that the `CryptographicException` becomes terminated due to the `ArgumentException` exception thrown from the enclosing finally block, as removing the `catch (CryptographicException)` block causes the exception to go unhandled and terminate the runtime? Since the runtime seems to be handling the `CryptographicException` when the `catch (CryptographicException)` block is present, why is the code inside of the block not executing? Extra informational Edit I'm still looking into the actual behavior of this, and many of the answers have been particularly helpful in at least answering parts of the above questions. Another curious behavior, that happens when you run the code with the `catch (CryptographicException)` block commented out, is the difference between .NET 4.5 and .NET 3.5. .NET 4.5 will throw the `CryptographicException` and terminate the application. .NET 3.5, however, seems to behave more according to the C# spec where the exception. ``` Propagate, my children Throwing CryptographicExecption Unhandled Exception: System.Security.Cryptography.CryptographicException [...] ram.cs:line 23 Throwing ArgumentException Caught ArgumentException Made it out of the exception minefield ``` In .NET 3.5, I see what I read in the spec. The exception becomes "lost", or "terminated", since the only thing that ever needs to get caught is the `ArgumentException`. Because of that the program can continue execution. I only have .NET 4.5 on my machine, I wonder if this happens in .NET 4.0?