Hi,
Colleagues of mine had an isse with a ThreadAbortException (used heavily in ASP.NET)
The exception was caught in a catch-block "catch (ThreadAbortException)". As you know the exception has to be rethrown by the runtime after the finally block even if there is no "throw;"-statement in the catch-block.
This happened with a C#6-build, 64-bit Architecture (don't know if build-setting or runtime-architecture. Probably "Any CPU"), .NET 4.5.x-Runtime. So it seems like a problem with the C#6-Output.
We do not have a repro-sample at the moment since this happened on a testing-machine in a complicated try/catch-scenario.
The work-around was to add a "throw;" in the "catch (ThreadAbortException)"-block. This should not be needed! This behaviour can be problematic if there is a "catch (Exception)"-block without a "throw;".
This can obiously break the standard ASP.NET-behaviour and cause havoc in IIS!
Can anyone look into this?
Thank you and kind regards
Hi,
Colleagues of mine had an isse with a ThreadAbortException (used heavily in ASP.NET)
The exception was caught in a catch-block "catch (ThreadAbortException)". As you know the exception has to be rethrown by the runtime after the finally block even if there is no "throw;"-statement in the catch-block.
This happened with a C#6-build, 64-bit Architecture (don't know if build-setting or runtime-architecture. Probably "Any CPU"), .NET 4.5.x-Runtime. So it seems like a problem with the C#6-Output.
We do not have a repro-sample at the moment since this happened on a testing-machine in a complicated try/catch-scenario.
The work-around was to add a "throw;" in the "catch (ThreadAbortException)"-block. This should not be needed! This behaviour can be problematic if there is a "catch (Exception)"-block without a "throw;".
This can obiously break the standard ASP.NET-behaviour and cause havoc in IIS!
Can anyone look into this?
Thank you and kind regards