I've read the posts ASP.NET application pool shutdown problem and IIS 7.5: problem with Application pool but they didn't answer my question.
I've got a C# ASP.NET page that in code-behind instantiates a class from a DLL supplied via the BIN directory, then calls a method on this instance. The method inside the DLL throws System.ArgumentException
due to a non existing column in a DataRow
object. The event log shows the following error:
Source: ASP.NET 2.0.50727.0
Application ID: /LM/W3SVC/1/ROOT/...
Process ID: 9476
Exception: System.ArgumentException
Message: Column 'someColumn' does not belong to table.
StrackTrace:
The calling code in the ASP.NET page wraps the method call in a generic try-catch
block. When I request the page, this crashes the corresponding application pool of my IIS instance and my web site is no longer available (Error 503). I manually have to restart the application pool and the site works again.
Update
As requested the try catch
block from the ASP.NET code behind:
try
{
SomeExternalClass someExternalClass = new SomeExternalClass();
someExternalClass.SomeMethod( someId );
}
catch( Exception ex )
{
// "smp" is an instance of "StatusMessagePanel", a control we use on all pages
// to show error information, basically a div container with an icon.
smp.ShowError( ex.Message );
}
Now my question is why a relatively "simple" exception such as the System.ArgumentException
being thrown when trying to access a non existing DataRow
column, crashes the whole website? Neither does the generic try-catch
block of the ASP.NET page help, nor should this be the reason to completely make the whole website unavailable, or is that a wrong assumption? I'd never have thought that this can basically take the (II)server down.
In anticipation of people telling me that I should check for column existence before I access them: I know about that and the legacy code has now been changed, but this isn't my question as described above, I'd like to know why the consequences are so drastic.
Update 2
The method in question being called inside the DLL starts a thread that is wrapped in a try-catch
block:
[...]
try
{
ThreadStart starter = () => CreateReport(...)
Thread thread = new Thread( starter );
thread.Start();
if( !thread.Join( TimeSpan.FromMinutes( 15 ) ) )
{
// Log some timeout warning
}
else
{
// Log information about successful report generation
}
}
catch( Exception ex )
{
// Log error information
}