[RESOLVED] Can the numbers on the left side be used as error reporting posisition

[FunkMonkey]

Can the numbers on the left side of the screen be used in error reporting? This would make locating errors much easier. It was not possible, easily, in VBA.

[jmcilhinney]

This is a situation where a screenshot would be useful. I think we can probably guess what you're talking about but it would be nice to be sure. If you're talking about the line numbers in the VS code window then the answer is yes and no. When you run a Debug build of your app, those line numbers are already used in exceptions. If you check the stack trace of an exception, you'll see that the line that threw the exception and each line in the call stack in recorded. When you run a Release build though, which your deployed app should be, then the line numbers are not provided by default. I'm not 100% sure about this but they may be included if you deploy the PDB file(s) with your EXE and/or DLL files. If you want to write code to get the line numbers yourself, you can use the StackFrame.GetFileLineNumber method.

[Shaggy Hiker]

I'm not sure that the line numbers are necessarily meaningful in the case of a release version. In the debug version of code, a line in the source equates to a line executed, but that need not be the case in the release version...though it often IS the case, just to make things a bit more confusing. Release versions can optimize away some code that it has determined is meaningless, which means that line X may not be executed. I think that, if line X is left out, and an exception happens on line X+N, then X+N is what would be reported, in which case the fact that X is optimized away doesn't matter, but there are some narrow cases where this can make things a bit confusing. Knowing the line number, in those cases, would only, "get you in the right neighborhood."

[.paul.]

@ Shaggy Hiker - I think that this is another attempt by the OP to use the (classic vb) VBA error handling methods. With On Error GoTo etc or On Error Resume Next, you use the Erl statement to retrieve a line number…

[jmcilhinney]

I'm not sure that the line numbers are necessarily meaningful in the case of a release version. In the debug version of code, a line in the source equates to a line executed, but that need not be the case in the release version...though it often IS the case, just to make things a bit more confusing. Release versions can optimize away some code that it has determined is meaningless, which means that line X may not be executed.

I did mean to include this information in my post but neglected to, so thank you for picking up my slack.

[TysonLPrice]

Here is a routine we use. The line number is correct most of the time as far as I have seen:

The call:

Dim mErrorMessage as string
mErrorMessage = "Error in cboParent_SelectedIndexChanged() - Line number: " & GetExceptionInfo(ex)
MsgBox(mErrorMessage)

The routine:

 Public Function GetExceptionInfo(ex As Exception) As String
        Dim Result As String
        Dim hr As Integer = Runtime.InteropServices.Marshal.GetHRForException(ex)
        Result = ex.GetType.ToString & "(0x" & hr.ToString("X8") & "): " & ex.Message & Environment.NewLine & ex.StackTrace & Environment.NewLine
        Dim st As StackTrace = New StackTrace(ex, True)
        For Each sf As StackFrame In st.GetFrames
            If sf.GetFileLineNumber() > 0 Then
                Result &= "Line:" & sf.GetFileLineNumber() & " Filename: " & IO.Path.GetFileName(sf.GetFileName) & Environment.NewLine
            End If
        Next
        Return Result
    End Function

[Shaggy Hiker]

@ Shaggy Hiker - I think that this is another attempt by the OP to use the (classic vb) VBA error handling methods. With On Error GoTo etc or On Error Resume Next, you use the Erl statement to retrieve a line number…

It has been far too long since I have written in VBA to any extent. I wasn't aware of that.

If that is the case, it's not the way to go. While On Error still works in .NET, it shouldn't be used. Structured exception handling is the more efficient, easier to maintain, approach. On the other hand, I'm not sure that there is a performance implication to using On Error style error handling. For a conversion project, sticking with On Error might be appealing, but I don't think you'd be able to rely on line numbers for that. They may well be meaningless.

[FunkMonkey]

It has been far too long since I have written in VBA to any extent. I wasn't aware of that.

If that is the case, it's not the way to go. While On Error still works in .NET, it shouldn't be used. Structured exception handling is the more efficient, easier to maintain, approach. On the other hand, I'm not sure that there is a performance implication to using On Error style error handling. For a conversion project, sticking with On Error might be appealing, but I don't think you'd be able to rely on line numbers for that. They may well be meaningless.

Thanks Guys. The reason I ask is becaus VBA does not report based on line number, Unless you do a lot of work to get it. Just wanted to know if VB was easier to get the line number for an error. Sounds like the error thrown is a lot clearer in VB.

[FunkMonkey]

This is a situation where a screenshot would be useful. I think we can probably guess what you're talking about but it would be nice to be sure. If you're talking about the line numbers in the VS code window then the answer is yes and no. When you run a Debug build of your app, those line numbers are already used in exceptions. If you check the stack trace of an exception, you'll see that the line that threw the exception and each line in the call stack in recorded. When you run a Release build though, which your deployed app should be, then the line numbers are not provided by default. I'm not 100% sure about this but they may be included if you deploy the PDB file(s) with your EXE and/or DLL files. If you want to write code to get the line numbers yourself, you can use the StackFrame.GetFileLineNumber method.

Sorry, I'll do that next time.

[Shaggy Hiker]

Thanks Guys. The reason I ask is becaus VBA does not report based on line number, Unless you do a lot of work to get it. Just wanted to know if VB was easier to get the line number for an error. Sounds like the error thrown is a lot clearer in VB.

Well, I wouldn't say that. Error messages tend to be...opaque, to say the least. Some people write useful error messages, but Microsoft is not normally in that camp. What you CAN get from errors is a stack trace. That's useless to the average person, but quite useful for debugging purposes. I wouldn't show a stack trace in an error message, but logging it somewhere would be useful.

[Niya]

There's really no need for line numbers. The exception system in .Net produces a full stack trace which gives far more information than just a line number.