How to get most info from exception

Discussion in 'ASP .Net' started by Jonah Olsson, Feb 16, 2004.

  1. Jonah Olsson

    Jonah Olsson Guest

    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
     
    Jonah Olsson, Feb 16, 2004
    #1
    1. Advertising

  2. Jonah Olsson

    Scott M. Guest

    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" <> wrote in message
    news:uQ%...
    > 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., Feb 16, 2004
    #2
    1. Advertising

  3. Jonah Olsson

    Jonah Olsson Guest

    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." <> skrev i meddelandet
    news:...
    > 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, Feb 16, 2004
    #3
  4. Jonah Olsson

    Scott M. Guest

    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" <> wrote in message
    news:...
    > 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." <> skrev i meddelandet
    > news:...
    > > 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.

    >
    >
     
    Scott M., Feb 16, 2004
    #4
  5. Jonah Olsson

    Jonah Olsson Guest

    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." <> skrev i meddelandet
    news:...
    > 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, Feb 16, 2004
    #5
  6. Jonah Olsson

    Scott M. Guest

    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" <> wrote in message
    news:%...
    > 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." <> skrev i meddelandet
    > news:...
    > > 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.

    >
    >
     
    Scott M., Feb 16, 2004
    #6
  7. Jonah Olsson

    Jonah Olsson Guest

    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." <> skrev i meddelandet
    news:...
    > 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, Feb 16, 2004
    #7
  8. Jonah Olsson

    Scott M. Guest

    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.


    "Jonah Olsson" <> wrote in message
    news:...
    > 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." <> skrev i meddelandet
    > news:...
    > > 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.

    >
    >
     
    Scott M., Feb 16, 2004
    #8
  9. "Jonah Olsson" <> wrote in message
    news:uQ%...
    > 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.
    --
    John Saunders
    John.Saunders at SurfControl.com
     
    John Saunders, Feb 17, 2004
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Vasanth
    Replies:
    0
    Views:
    599
    Vasanth
    Jun 28, 2004
  2. H.MuthuKumaraRajan
    Replies:
    3
    Views:
    490
    H.MuthuKumaraRajan
    Feb 4, 2004
  3. xkenneth
    Replies:
    8
    Views:
    367
    Bruno Desthuilliers
    Feb 6, 2008
  4. ilya

    get CPU info, RAM info

    ilya, Apr 8, 2010, in forum: Java
    Replies:
    43
    Views:
    6,254
    Mike Schilling
    Apr 19, 2010
  5. amit
    Replies:
    0
    Views:
    96
Loading...

Share This Page