How do I set CallStack="false" but still get the exception in a custom error handler?

Question

I've got a pretty custom SharePoint 2010 Server solution. We have a custom HttpModule setup for error handling (relevant code provided below):

   public class ErrorHandlerModule : IHttpModule
    {
        public void Application_Error(object sender, EventArgs e)
        {

            HttpContext Context = HttpContext.Current;
            Exception exception;

            for (exception = Context.Server.GetLastError(); exception.InnerException != null; exception = exception.InnerException) { }

            //Log and redirect user to custom error page as appropriate - code excluded for clarity/conciseness
        }
    }

We also have the following relevant items specified in the web.config:

<SharePoint>
 <SafeMode CallStack="true" ></SafeMode>
</SharePoint>

<system.web>
 <customErrors mode="On" defaultRedirect="~/_layouts/custom/ErrorHandler.aspx" />
</system.web>

<system.webServer>
 <modules>
  <add name="CustomErrorHandler" preCondition="integratedMode" type="OurApp.Common.HttpModules.ErrorHandlerModule, OurApp.Common, Version=1.0.0.0, Culture=neutral, PublicKeyToken=abc123..." />
 </modules>
</system.webServer>

We've inherited the code/setup, and see noted that "CallStack='true'" is not ideal (except for development environments). We are looking to change this attribute setting back to 'false' for all non-development environments, however, we notice that in doing so, the code in our custom event handler is not able to obtain a reference to valid exception via the "Context.Server.GetLastError()" method call. When we switch it back to CallStack='true', we are able to get a valid Exception object reference using the same "Context.Server.GetLastError()" method call. The example scenario where I "raise" an error that is handled by this is in a custom List Item event receiver where I set the Cancel and Error Message properties (for example in an ItemAdding or ItemUpdating event):

public override void ItemUpdating(SPItemEventProperties properties)
{
  properties.Cancel = true;
  properties.ErrorMessage = "An error that we control happened.";
  return;      
}

It seems odd to me that a "SharePoint specific" attribute in the web.config would change the behavior of the core ASP.NET Server.GetLastError() method call.

UPDATE: I've also tried with an Application page (_layouts) that inherits from the base System.Web.UI.Page, rather than any of the SharePoint specific Layouts page base classes, and threw exception in Page_Load. I am seeing the same behavior - with callstack="true" I can access the exception from Context.Server.GetLastError() in the error handling module, however, with callstack="false" (the ideal setting value), I am not able to get a valid exception reference.

public class ErrorTest : System.Web.UI.Page
{
    protected override void OnLoad(EventArgs e)
    {
        throw new Exception("blah");
    }
}

END UPDATE

My understanding of the CallStack attribute is that it affects whether error details are surfaced in the UI, not the API. Am I understanding this incorrectly? Should I expect the behavior to be changed in the underlying API?

Answer 1

Long story short - you don't. The CallStack attribute specifically hides this information, to prevent users from getting the very information you are trying to get.

The point of the "Callstack = false" being best practices is because if this is set to "True", too much information is exposed to users - if you are intercepting this process and injecting your own error page instead of displaying the out-of-the-box error page, this supersedes this best practice.

Just be sure that if your logic has a "Fall-through" condition that would eventually land on the out-of-the-box SharePoint error page, that you handle the error and pass through a "An unexpected error has occurred" (Or maybe something useful) to the OOTB handler.

If you take a look at the following article (From '03, but still relevant) and search for "callstack", you will see that it mentions that it is only not appropriate for production use because it exposes too much information - if you are hiding this information, you have nothing to fear. http://msdn.microsoft.com/en-us/library/dd583135(v=office.11).aspx