How to get most info from exception

[Jonah Olsson]

Hi guys,

For my VB.NET application, I created an ErrorHandler class that should save
all available information about the last error occurred. I use
Server.GetLastError for this.
The problem is that I quite often get errors that I really can't say why
they happen because of the lack of information from GetLastError. This is an
example:

System.NullReferenceException: Object reference not set to an instance of an
object.
at MyApp.GlobalApp.Application_BeginRequest(Object sender, EventArgs e)
at
System.Web.SyncEventExecutionStep.System.Web.HttpApplication+IExecutionStep.
Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean&
completedSynchronously)

Is this really all I can get from the exception? How can I tell what really
happened since our test group hasn't found any bugs when testing the site?

Thanks.

Best regards,
Jonah Olsson

 

[Scott M.]

Instead of Server.GetLastError (which was the Classic ASP way of finding and
dealing with errors), use Structured Exception Handling which traps the
execption in line with your code and let's you handle different types of
exceptions.

The first step is to identify what line(s) of code are crashing the
application and then wrapping them in a "Try" statement. Then include a
"Catch" statement for each possible exception type. In each "Catch", you
can interrogate the exception using its .Message, .getType() and .source
members.

Take a simple "answer = number1 / number2" for example:

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
Dim x, y as Short
Try
x = txtBox1.text
y = txtBox2.text
txtBox3.text = x / y
Catch ex As System.OverflowException
txtErrMessage.text = "Your number was out of the acceptable range"
Catch ex As System.InvalidCastException
txtErrMessage.text = "Please enter numeric data only."
Catch ex As Exception
txtErrMessage.text = "Error of type: " & ex.GetType.ToString
End Try
End Sub

With "Option Strict" turned on, we will get an InvalidCastException when we
attempt to make x = txtBox1.text, the first Catch statement will be hit.

If we enter extremely large or small values, we will get an
OverflowException and for anthing that we couldn't predict, the generic
"Catch" will be hit and we will display what kind of exception we did get in
that case.

 

[Jonah Olsson]

Hi Scott,
and thanks for your reply!

I know of Try/Catch, but I thought there might be another (global) way of
tracking all errors within the application without using the Try/Catch
statement and still get detailed information.

How can I find/identify the line that are crashing the application without
being able to get more information from GetLastError? That is, I don't know
where to include the Try/Catch statement :-/

Thanks.
Jonah

 

[Scott M.]

Determining where the application is crashing should be easy. Look at the
error page that comes up in the browser and it will tell you (in red) what
line raised the exception.

You can, of course, step through your code in the debugger and see what line
it dies on.

In my opinion, you shouldn't be using Server.GetLastError at all anymore
(although it is still supported). Structured exception handling is the
new/improved mechanism.

 

[Jonah Olsson]

Yes, I do know that structured exception handling is the best/only way, but
in this case it seems like I haven't include any Try/Catch statement in this
part of the code.
As I wrote in my first post, non of our test group members has found this
problem, nor do I when I run debug or test it myself. This is just reported
every now and then through emails using a function with GetLastError called
from Application_BeginRequest.

I was just curious if I could get more information from GetLastError to help
me track down this kind of problem.

Jonah

 

[Scott M.]

Ok Jonah, I got you now. Your first post didn't really say that the errors
were being reported by users of the application, rather than the developer
of the application.

Well, and I wouldn't recommend this as a normal bit of code, but you could
wrap each (or the suspected) procedure's code inside ONE Try statement and
have ONE catch that you can interrogate:

Sub Page_Load(sender as object, e as eventArgs)
Try


...All the code from the procedure goes here...


Catch ex as Exception
lblErrorMessage.Text = "Exception Type: " & ex.getType.ToString() &
"Exception Source: " & ex.source.ToString()
End Try
End Sub

You could do this for each procedure until you tracked the culprit down. I
know this seems like a lot of extra code, but in reality, you should really
be using Try...Catch wherever the possibility of exceptions (that are not
preventable) may exist.

 

[Jonah Olsson]

Thanks for you help! I really appreciate it.
And I'm sorry for not being clear enough in my first post.

I think I have to go through all my code then and insert Try/Catch
statements where those are missing.

Again, thanks for you help and time!

Regards,
Jonah Olsson

 

[Scott M.]

Good luck Johah. I think you'll find that it will get easier to incorporate
Try...Catch after you see how easy it is to handle the exceptions and even
develop and throw your own custom exceptions.

 

[John Saunders]

Hi guys,

For my VB.NET application, I created an ErrorHandler class that should save
all available information about the last error occurred. I use
Server.GetLastError for this.
The problem is that I quite often get errors that I really can't say why
they happen because of the lack of information from GetLastError. This is an
example:

System.NullReferenceException: Object reference not set to an instance of an
object.
at MyApp.GlobalApp.Application_BeginRequest(Object sender, EventArgs e)
at
System.Web.SyncEventExecutionStep.System.Web.HttpApplication+IExecutionStep.
Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean&
completedSynchronously)

Is this really all I can get from the exception? How can I tell what really
happened since our test group hasn't found any bugs when testing the site?

That's all you can get if you don't have debug symbols. With debug symbols,
you'll get the line number and source file.

Is there any other information you're looking for?

Some exceptions do carry more information. For example, an SqlException will
tell you the database server, stored procedure name and line number, and the
SQL Server error code. Your Application_Error handler can check to see what
kind of exception you received and can display any details available.