Hello,
I just ran into an issue with how the core handling ThreadAbortExceptions generated by Response.Redirect or Response.End. Specifically, it has to with exceptions generated from within ActionBase.ProcessAction(). Here is the scenario:
When ProcessAction() is called with ModuleActionType.DeleteModule, it in turn calls ActionBase.Delete(). Delete() ends with call Response.Redirect, which (per http://support.microsoft.com/kb/312629) generates a ThreadAbortException. Now, everywhere ProcessAction is called (e.g. DropDownActions.ascx.vb, LinkActions.acsc.vb, SolPartActions.vb, etc.), it is called withing a Try..Catch clause. This means the ThreadAbortException is handled and discarded, and processing continues.
Where this became an problem was when my code tried to call GetModuleInfo(ModuleId, TabId) after the call to ActionBase.Delete(). In this case, the module had already been deleted, so the call returns Nothing, leading to other errors.
I fixed my code to account for this, but it seemed strange for module's initialization code to be called after it had already been deleted. At the very least, it seems to be a performance issue in that all this code is getting executed for nothing since the page is going to redirect anyway. So here's my questions:
Does anyone think this is a bug? Should the core code avoid handling ThreadAbortExceptions like this? Before I log this in Gemini, I figured I'd look for input here....
Thanks,
-Drew