Long waited attempt to handle exceptions properly.

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Unfortunately I've used exception handling as a debugging tool.
Now I want to be smarter about handling errors. Today in the global.asx in the Application_OnError event, I inserted code to email me the Server.GetLastError with some other information.
Everythings working fine, but the information about the last error isn't useful. I stilll have to step through the program (VS.NET 2003) to find exactly where the error(s) originate.

Tell me if this is right.

1. The Code Behind uses and Object (dll).

2. Object uses another Data Access Object to retrieve data.

Here I know SQLException is being raised because I purposely changed the connect string.

I have no try catch blocks.

So......

If I throw Exceptions from the Data Access Object and the Code behind......will I receive more info about the error.

I'll give more detailed info...if needed, but someone with experience should know what I'm talking about.


While I'm testing myself.....I like hearing peoples opinions.

Thanks,
Lee
 
the further away from the exception you catch it, the less likely you are to
have its context. catching errors at the global level is a last resort move.
you should try to catch at the page level before global. you should be
wrapping code with try catch blocks where you expect errors may occur so you
can handle them at this point and continue.

You may be able to glean more information from the Error property of the
Context object which returns the first exception object accumulated during
http processing.

regards

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
Unfortunately I've used exception handling as a debugging tool.
Now I want to be smarter about handling errors. Today in the global.asx
Click to expand...
in the Application_OnError event, I inserted code to email me the
Server.GetLastError with some other information.
Everythings working fine, but the information about the last error isn't
Click to expand...
useful. I stilll have to step through the program (VS.NET 2003) to find
exactly where the error(s) originate.
Tell me if this is right.

1. The Code Behind uses and Object (dll).

2. Object uses another Data Access Object to retrieve data.

Here I know SQLException is being raised because I purposely changed the connect string.

I have no try catch blocks.

So......

If I throw Exceptions from the Data Access Object and the Code
Click to expand...
behind......will I receive more info about the error.
I'll give more detailed info...if needed, but someone with experience
Click to expand...
should know what I'm talking about.
 
You could add additional info to each catch like this

catch(Exception eX)
{
string sErr = "Error in blah.aspx, SomeFunction() " + eX.Message;
SendError(sErr);
}

plus any other relevent info so you know what file and what function
threw the error.

(e-mail address removed)
http://www.studentshopper.com/
 
Thank you,

I need to improve my developing of systems. Along with
commenting code, handling exceptions seemed be something
I only used while in debug mode.


If I catch an error before the last line of defense, most
of the time it's just to log the info and then I (by
habit) just throw a new exception with some additional
message.

If I just throw exceptions up the stack.....Is that
additional information going to appear at the global
level ?

I'm also looking for other uses besides logging and
sending messages. Or is that the primary use ?
 
The primary reason for rethrowing an exception is to interpret the catched
exception and interpret it as your own (add or retract information from it).
One gotcha is that when you rethrow, the run-time now only knows the point
of origin at the rethrow line. It doesn't know that the exception came from
deeper in the code so the rethrow becomes the point of origin. However, if
you append information from the original exception you can work around this.

There are lots of other uses, for example, you can redirect back to the
calling page so that the page starts over again automatically after a
critical error.
 
Back
Top