Stack Trace Fails To Report Line Of Exception?

[Mario T. Lanza]

Greetings,

I have been capturing and logging exceptions in an application I
developed. I've noticed for some time now that certain exceptions
track back to the Application.Run method and provide no other line
number useful for identifying the actual line throwing the exception.

For example:

at System.Windows.Forms.SafeNativeMethods.ShowWindow(HandleRef hWnd,
Int32 nCmdShow)
at System.Windows.Forms.Control.SetVisibleCore(Boolean value)
at System.Windows.Forms.Form.SetVisibleCore(Boolean value)
at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
at System.Windows.Forms.Form.ShowDialog()
at System.Windows.Forms.ThreadContext.OnThreadException(Exception t)
at System.Windows.Forms.Control.WndProcException(Exception e)
at System.Windows.Forms.ControlNativeWindow.OnThreadException(Exception
e)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg,
IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageA(MSG& msg)
at System.Windows.Forms.ComponentManager.System.Windows.Forms.UnsafeNativeMethods+IMsoComponentManager.FPushMessageLoop(Int32
dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.ThreadContext.RunMessageLoopInner(Int32
reason, ApplicationContext context)
at System.Windows.Forms.ThreadContext.RunMessageLoop(Int32 reason,
ApplicationContext context)
at System.Windows.Forms.Application.Run(Form mainForm)
at Clarity.Cashflow.Interface.TransactionForm.Main(String[] args) in
c:\documents and settings\mlanza\my documents\visual studio
projects\clarity.cashflow.satellite\interface\transactionform.cs:line
369

Line 369 appears below:

TransactionForm frm;

try
{
frm = new TransactionForm();
Application.Run(frm); //line 369
}
catch(System.Exception ex)
{
Core.ErrorLog.AddEntry(ex);
}

As you might guess, this is not very useful. Of course, I know the
exception was thrown somewhere within the context of my whole
application, just not the actual line number. Yes, there are a number
of clues provided in the stack trace, but nothing half as useful as an
actual line number.

My guess is that for this to happen, the actual line number must not
be wrapped in a try-catch block. Now, for the most part, I have
try-catch blocks everywhere throughout my application. Upon recent
review I discovered I was doing something unusual -- I have try-catch
blocks wrapping calls to events that are handled in turn by the even
subscriber. When I wrote this logic it was my understanding that such
a try-catch block would still do the trick.

For example:

try
{
RequestInputEventArgs ri = this.OnRequestInput("Enter Transaction
Remarks", prompt, cdt, false, String.Empty);
}
catch(System.Exception ex)
{
Core.ErrorLog.AddEntry(ex);
}

The subscriber method:

private void TransactionManager_RequestInput(object sender,
RequestInputEventArgs e)
{
InputBox input = new InputBox(e.Caption, e.Prompt, e.DefaultText,
e.ValidDataType, e.AllowEmptyString);
input.ShowDialog(this);
e.Cancel = input.Cancel;
if (!e.Cancel)
e.InputText = input.InputText;
}

As you can see, there in no error handler in the subscriber. I am
assuming the error handler in the class raising the event is still in
effect for catching errors, even those thrown in the subscriber. Is
this true?

If so, does anyone have an other ideas why my stack traces aren't
pinpointing the actual line numbers?

Mario T. Lanza
Clarity Information Architecture, Inc.
2004.09

 

[mike]

I believe this is because you're building a *release* version (no line-level
symbol detail)