[RESOLVED] [2005] Error Line Numbers

[clarkgriswald]

Is there any way to get the actual line number that an error occurs on in conjunction with the Throw statement? Here is a sample:

Private Sub TestErrors()
 
        Try
 
            Dim i As Integer
 
            i = 5
 
            i *= 3
 
            CreateError(i)
 
        Catch ex As Exception
            DisplayException(ex)
        End Try
 
    End Sub
 
    Private Sub CreateError(ByVal i As Integer)
 
        Try
 
            Dim n As Integer
 
            n = CInt(i / n)
 
        Catch ex As Exception
            Throw ex
        End Try
 
    End Sub

In this example, the error stack will report lines 11 and 28 as the error line numbers. I really want to know that line 25 is the "real" root of the error and that line 28 is just where the error was thrown. If I were to handle the exception rather than use a throw, then the stack would report line 25. The problem is, that I need to use throw in many of my objects to allow the calling application to handle exceptions. Any ideas or thoughts?

[Shaggy Hiker]

I'm curious as to why the line number is important? If the code was altered, the line number would change, so it is only a reasonably constant pointer in well settled code. Naturally, the example you posted is a trivial simplification of the real issue you are interested in, but I wonder if that doesn't illustrate the issue well. The only place I can think that the line number would be particularly important is if the calling app was a test suite testing the called code. Otherwise, either the type of exception or the fact of an exception, would be relevant, but the exact location would not.

[clarkgriswald]

Good question. When an error occurs in our application, we have an exception object that handles the exception and displays a user friendly dialog to the user. If the problem persists, they can report the error to our support team and embedded in that information is the stack trace of the error. The line number will tell us the exact line the error occurred on. Make sense?

[Shaggy Hiker]

Yes. The result is that your reporting system is effectively the module testing that I mentioned above, you are simply using the end users to test for bugs. That almost sounds mean, but in fact it is the model my agency is using explicitly. Unless you have a very extensive testing structure, the end users will always find bugs.

I have not tried this, so the following suggestion is as likely to be meaningless as meaningful, but here it is: In VB6 you had the ability to create custom errors. In .NET, you can create custom derivations of the Exception class. In your example, you simply re-throw the exception that got you to the first handler. I would suggest that you make a custom exception that contains the line number or stack trace, and throw that instead. Basically, this would mean having some canned routine (I would expect it to be standard code that could be cut and pasted) that can be pasted into each exception handler that takes the exception in the inner catch, creates a new exception of the custom type with the relevant information contained in something (like the message, tag, or other property), then throws that custom exception.

[clarkgriswald]

Hmmm, interesting approach. Any ideas as to why the "root" line number is lost or to why I receive no line number sometimes?

[Shaggy Hiker]

The exception class should have a stack trace. However, once you handle the exception, then re-throw, I expect that the system is treating the re-throw as a whole different exception distinct from the original one, despite the fact that you are really just re-throwing. I would guess that's some kind of internal counter issue, but I have never really looked into it.

[clarkgriswald]

Ah, very interesting...kind of annpying, but your explanation makes sense. Thanks!

[wild_bill]

I expect that the system is treating the re-throw as a whole different exception distinct from the original one, despite the fact that you are really just re-throwing. I would guess that's some kind of internal counter issue, but I have never really looked into it.

that is true in this case

Private Sub CreateError(ByVal i As Integer)
         Try
             Dim n As Integer
             n = CInt(i / n) 
        Catch ex As Exception
            Throw ex
        End Try
     End Sub

But you can preserve the original exception by doing this

Private Sub CreateError(ByVal i As Integer)
         Try
             Dim n As Integer
             n = CInt(i / n) 
        Catch ex As Exception
            Throw
        End Try
     End Sub

[clarkgriswald]

The results appear to be the same whether I use Throw versus Throw ex. Not really sure what the difference is as both report the same error stack.

[ntg]

My stupid suggestion would be to remove the Try/Catch block from the CreateError method since it only serves to re-throw the exception. BTW, I think that CLR is correct in reporting line 28 as the one that caused the error since you caught it with the Catch block. The stack trace of the exception will probably not be useful since it includes a list of code locations that have thrown an exception.

[clarkgriswald]

Removing the Try/Catch block is not good coding practice so I do not want to do that (I'm sure there are also other reasons that this is not a good idea). As I had mentioned, if I handle the error in the initial Catch statement, the error line number will be 25, which is what I want. I want the line the error occurred, not the line that threw the error.

There has to be some explanation for this, I'm just not getting it.

[jmcilhinney]

You should create a new exception object and assign the original exception to its InnerException property. The InnerException will then have the original line number. To see what I mean, try this code:

Private Sub Method1()
    Try
        Me.Method2()
    Catch ex As Exception
        MessageBox.Show(ex.ToString())
    End Try
End Sub

Private Sub Method2()
    Try
        IO.File.Open("This file does not exist", IO.FileMode.Open)
    Catch ex As Exception
        MessageBox.Show(ex.ToString())
        Throw
    End Try
End Sub

You'll see that the first message has the original line number but the second message has the line number of where the exception was rethrown. Now try this code:

Private Sub Method1()
    Try
        Me.Method2()
    Catch ex As Exception
        MessageBox.Show(ex.ToString())
    End Try
End Sub

Private Sub Method2()
    Try
        IO.File.Open("This file does not exist", IO.FileMode.Open)
    Catch ex As Exception
        MessageBox.Show(ex.ToString())
        Throw New Exception("Outer Exception", ex)
    End Try
End Sub

You''l see that the second message still shows the line number of where the new exception was thrown but it also includes the stack trace for the inner exception, which includes the original line number.

[Edneeis]

I agree with the above. This is what the inner exception is meant for.
Also note that line numbers will only appear if the pdb is distributed in the release environment. no pdb means no line numbers since the numbers are coming from the debug info in the pdb file.