Error linenumber

  • Thread starter Thread starter Le, Thanh-Nhan
  • Start date Start date
L

Le, Thanh-Nhan

Hi,
Can I retrieve the linenumber of code where current error occurs (as in
Visual Basic or Java)?

Thanks
 
Hi,

Provided you have debugging information embedded, you can use the
System.Diagnostics.StackTrace class to examine all stack traces involved and
their respective locations in source code.
 
Thanks,

I have tried the following code, but Filename is empty and linenumber is
always 0. Why? I run the application from VS Studio, debug modus.
try
{
g_oDBLocal.Open();
}
catch( System.Data.OleDb.OleDbException ex)
{
System.Windows.Forms.MessageBox.Show(ex.Message);
System.Diagnostics.StackTrace st = new
System.Diagnostics.StackTrace(ex);
System.Diagnostics.StackFrame sF;
int i;
for (i=0; i< st.FrameCount; i++)
{
sF = st.GetFrame(i);
MessageBox.Show(sF.ToString() + "\n" + sF.GetFileName() + ", Line "
+ sF.GetFileLineNumber());
}
return false;
}

Nhan

Dmitriy Lapshin said:
Hi,

Provided you have debugging information embedded, you can use the
System.Diagnostics.StackTrace class to examine all stack traces involved and
their respective locations in source code.

--
Sincerely,
Dmitriy Lapshin [C# / .NET MVP]
Bring the power of unit testing to the VS .NET IDE today!
http://www.x-unity.net/teststudio.aspx

Le said:
Hi,
Can I retrieve the linenumber of code where current error occurs (as in
Visual Basic or Java)?

Thanks
Click to expand...
Click to expand...
 
again,
What do you think about "Provided you have debugging information embedded"?


Dmitriy Lapshin said:
Hi,

Provided you have debugging information embedded, you can use the
System.Diagnostics.StackTrace class to examine all stack traces involved and
their respective locations in source code.

--
Sincerely,
Dmitriy Lapshin [C# / .NET MVP]
Bring the power of unit testing to the VS .NET IDE today!
http://www.x-unity.net/teststudio.aspx

Le said:
Hi,
Can I retrieve the linenumber of code where current error occurs (as in
Visual Basic or Java)?

Thanks
Click to expand...
Click to expand...
 
Le said:
What do you think about "Provided you have debugging information embedded"?
Click to expand...

The same is true with Java. If you compile Java with -g:none you won't
be able to get the line numbers there, either.
 
Hi,
I check the build options in VS NET: Project / Properties / Configuration
Properties / Build
Generate Debugging Information = True
Is it not enough? Please tell me, what I can do. I can use command line to
build project, but it is not comfortable, ...

Thanks
Nhan
 
Hi,

Please see the code below, the StackFrame.ToString() gives me following
Information

OpenLocalDB at offset 462 in file: line:column <filename unknown> :0:0

Can you tell me, what it means "offset nnn"

Thanks

catch( System.DivideByZeroException ex)
{
System.Diagnostics.StackTrace st = new
System.Diagnostics.StackTrace(ex);
System.Diagnostics.StackFrame sF;
int i;
for (i=0; i< st.FrameCount; i++)
{
sF = st.GetFrame(i);
MessageBox.Show(sF.ToString());
}
}
 
Le said:
Please see the code below, the StackFrame.ToString() gives me following
Information

OpenLocalDB at offset 462 in file: line:column <filename unknown> :0:0

Can you tell me, what it means "offset nnn"

Thanks

catch( System.DivideByZeroException ex)
{
System.Diagnostics.StackTrace st = new
System.Diagnostics.StackTrace(ex);
System.Diagnostics.StackFrame sF;
int i;
for (i=0; i< st.FrameCount; i++)
{
sF = st.GetFrame(i);
MessageBox.Show(sF.ToString());
}
}
Click to expand...

Well, without knowing what assembly OpenLocalDB is in, it's impossible
to say what's going on. If it's in an assembly which has been compiled
with debug information on, that should be fine.

Could you post a short but complete program which demonstrates the
problem?

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.
 
Here is my code. OpenLocalDB is only a private function. I set a false connectionstring to the connection, then open, so that an error occurs.

Thanks
Nhan

using System;
using System.Drawing;
using System.Collections;
using System.ComponentModel;
using System.Windows.Forms;
using System.Data;

public class frmMain : System.Windows.Forms.Form
{
public static DataSet ds;
public static System.Data.OleDb.OleDbConnection g_oDB, g_oDBLocal;
public frmMain()
{ }
private static void initproject()
{
if (!OpenLocalDB())
Application.Exit();
}

// [STAThread]
static void Main()
{
initproject();
Application.Run(new frmMain());
}

private static bool OpenLocalDB()
{
string conStr = "Provider=Microsoft.Jet.OLEDB.4.0;" ...

g_oDBLocal = new System.Data.OleDb.OleDbConnection(conStr);
try
{
g_oDBLocal.Open();
}
catch( System.Data.OleDb.OleDbException ex)
{
System.Windows.Forms.MessageBox.Show(ex.Message);
System.Diagnostics.StackTrace st = new System.Diagnostics.StackTrace(ex);
System.Windows.Forms.MessageBox.Show(st.ToString());
System.Diagnostics.StackFrame sF;
int i;
for (i=0; i< st.FrameCount; i++)
{
sF = st.GetFrame(i);
MessageBox.Show(sF.ToString() + "\n" + sF.GetFileName() + ", Line " + sF.GetFileLineNumber());
}
return false;
}

return true;
}
}
 
Le said:
Here is my code. OpenLocalDB is only a private function. I set a
false connectionstring to the connection, then open, so that an error
occurs.
Click to expand...

<snip>

Okay. Of course, all the GUI stuff is extraneous, but anyway...

I'll have look into why you're not getting the extra information.
 
This means 462 bytes into the intermediate language of the method that's
throwing the exception. This info would only be useful if you did an IL
disassembly on the compiled code to see exactly what was failing, but of
course you'd need to know what DLL the exception was thrown in.

I'd venture to guess that this is what's actually happening:

1) Your project is compiled with debug info, but there is only one line in
that project that can possibly be causing the catch -- the one line of code
that's in the try block. Therefore:

2) The exception is being thrown inside a .NET assembly, somewhere in the
chain of internal methods that is called as a result of g_oDBLocal.Open().
This internal code is NOT compiled in debug mode, which explains why you're
not getting file/line/column info in the stack trace.

So if you are working on a generic routine that walks the stack trace to get
the offending line number you will have to handle the possibility that the
exception is thrown in system or 3rd party code and you won't always be able
to get the line number (and of course you won't be able to get the line #
for your own code if your project is in release mode).

So I conclude that the routine mentioned in the stack trace, OpenLocalDB, is
a (probably protected or private) method within an assembly in the GAC
somewhere, most likely System.Data.dll.

--Bob

Le said:
Hi,

Please see the code below, the StackFrame.ToString() gives me following
Information

OpenLocalDB at offset 462 in file: line:column <filename unknown> :0:0

Can you tell me, what it means "offset nnn"

Thanks

catch( System.DivideByZeroException ex)
{
System.Diagnostics.StackTrace st = new
System.Diagnostics.StackTrace(ex);
System.Diagnostics.StackFrame sF;
int i;
for (i=0; i< st.FrameCount; i++)
{
sF = st.GetFrame(i);
MessageBox.Show(sF.ToString());
}
}
Click to expand...
 
Hi,
Now in my try block I have more than one line. But linenumber is still
always 0.
try
{
g_oDBLocal.Open();
ds = new DataSet();
string sSQL = "SELECT * FROM Customers";
OleDbDataAdapter da = new OleDbDataAdapter(sSQL, g_oDBLocal);
da.Fill(ds, "Kunden");
}
catch( System.Data.OleDb.OleDbException ex)
{
...
}


Bob Grommes said:
This means 462 bytes into the intermediate language of the method that's
throwing the exception. This info would only be useful if you did an IL
disassembly on the compiled code to see exactly what was failing, but of
course you'd need to know what DLL the exception was thrown in.

I'd venture to guess that this is what's actually happening:

1) Your project is compiled with debug info, but there is only one line in
that project that can possibly be causing the catch -- the one line of code
that's in the try block. Therefore:

2) The exception is being thrown inside a .NET assembly, somewhere in the
chain of internal methods that is called as a result of g_oDBLocal.Open().
This internal code is NOT compiled in debug mode, which explains why you're
not getting file/line/column info in the stack trace.

So if you are working on a generic routine that walks the stack trace to get
the offending line number you will have to handle the possibility that the
exception is thrown in system or 3rd party code and you won't always be able
to get the line number (and of course you won't be able to get the line #
for your own code if your project is in release mode).

So I conclude that the routine mentioned in the stack trace, OpenLocalDB, is
a (probably protected or private) method within an assembly in the GAC
somewhere, most likely System.Data.dll.

--Bob
Click to expand...
 
Hello,
Again,
In MSDN October 2001, there is a note, that property Linenumber,... "This
method is not yet implemented.". Can I understand, that this property is not
yet implemented in actual .NET Framework?

Nhan

Bob Grommes said:
This means 462 bytes into the intermediate language of the method that's
throwing the exception. This info would only be useful if you did an IL
disassembly on the compiled code to see exactly what was failing, but of
course you'd need to know what DLL the exception was thrown in.

I'd venture to guess that this is what's actually happening:

1) Your project is compiled with debug info, but there is only one line in
that project that can possibly be causing the catch -- the one line of code
that's in the try block. Therefore:

2) The exception is being thrown inside a .NET assembly, somewhere in the
chain of internal methods that is called as a result of g_oDBLocal.Open().
This internal code is NOT compiled in debug mode, which explains why you're
not getting file/line/column info in the stack trace.

So if you are working on a generic routine that walks the stack trace to get
the offending line number you will have to handle the possibility that the
exception is thrown in system or 3rd party code and you won't always be able
to get the line number (and of course you won't be able to get the line #
for your own code if your project is in release mode).

So I conclude that the routine mentioned in the stack trace, OpenLocalDB, is
a (probably protected or private) method within an assembly in the GAC
somewhere, most likely System.Data.dll.

--Bob
Click to expand...
 
Back
Top