Try/Catch question

[tshad]

Normally, I surround my Dataset/fill or DBreader execut with a try/Catch.

Something like:
******************************************************
Dim dbReader As SqlDataReader

Dim ConnectionString as String
=System.Configuration.ConfigurationSettings.AppSettings("MM_CONNECTION_STRING_Connection")
Dim objConn as New SqlConnection (ConnectionString)
Dim CommandText as String = "Select City,StateCode from zipCodes where
zipCode = @ZipCode and CityType = 'D'"
Dim objCmd as New SqlCommand(CommandText,objConn)
with objCmd.Parameters
.Add("@ZipCode",SqlDbType.VarChar,9).value = ZipCode.Text
end with

try
objConn.Open()

dbReader = objCmd.ExecuteReader

if dbReader.Read then
City.Text = dbReader("City")
State.Text = dbReader("StateCode")
end if
catch ex as Exception
... Do something
finally
objConn.Close()
end try
**************************************************************

I have someone here that writes his code where he surround all his code with
a try/catch, not just the area where he could logically expect to have a
problem. Sometimes he would surround all the code in one try/catch block
and nest another around the Sql section.

His reasoning is that if he gets an error, he wants to keep the user on a
page and give an error there instead of having it go to some general page.

I was curious about other ideas on this on whether this is a good ideas.
Just trying to get some pros and cons.

Thanks,

Tom

 

[tomb]

This is really a matter of application structure. If you want the user
to go somewhere else, then your way is better. However, you may find
that it will depend on the actual location/page/form your user is in
that will determine what action you want taken. Most of my applications
have both scenarios, and even include some functions that have no
try/catch in them at all because I want to handle errors from there
outside the function at all times.

Hope this helps.

Tom

 

[Jim Wooley]

Hello tshad,

Normally, I surround my Dataset/fill or DBreader execut with a
try/Catch.
I have someone here that writes his code where he surround all his
code with a try/catch, not just the area where he could logically
expect to have a problem. Sometimes he would surround all the code
in one try/catch block and nest another around the Sql section.

His reasoning is that if he gets an error, he wants to keep the user
on a page and give an error there instead of having it go to some
general page.

It really depends on what you are planning on doing with the exception information.
It is possible to let the exception bubble out of the data access method
(assuming it isn't just included in the Form_Load event, but encapsulated
elsewhere). For instance, you could just to the Try..Finally and dispose
of your connection in this method. The failure exception will bubble up to
the UI layer where you would handle it as necessary.

BTW, in your instance, you are just closing the connection. I understand
you need to dispose it as well to avoid memory leaks. If you are using 2.0,
you should use the Using keyword with your connection and data reader to
make sure they are disposed properly.

As for what to do with the error, it depends on whether the user can do anything
with the exception information. Don't simply post the exception information
to the end user. Give them viable options to fix the problem or notify them
that there is a problem and give them a way to contact someone for assistance.
If nothing else, you should log it somehow, otherwise you can get exceptions
and never know your code is failing.

Jim Wooley

 

[Cor Ligthert [MVP]]

Jim,

BTW, in your instance, you are just closing the connection. I understand
you need to dispose it as well to avoid memory leaks.

As often showed is this something from the past were some people probably
where mixing up finalize with dispose.

There is in the case of a connection not any advantage above disposing and
closing. Disposing takes only some extra instructions by instance with
removing the connectionstring from the connection object.

Cor

 

[CMM]

I would certainly not wrap EVERY method in a Try/Catch. This harkens back to
VB.Classic OnError model and the fact that an unhandled error would force
your app to blow up. This is no longer true in .NET (unless it happens like
during app startup).

However, (in ASP.NET specifically) sometimes you do want to wrap an entire
algorithm in a TryCatch block.... if only because in that *particular
instance* you don't want the user redirected to your generic error.htm (if
you've set one up... or the ugly unprofessional default ASP error page
otherwise). Like the others replied... it depends on the situation. But, as
a "general practice," the answer is absolutely not.

 

[Cor Ligthert [MVP]]

Tom,

It is as you wish, however if you want to do it more global, than is in my
idea the global exception handler better.

It is often handled by Jay in this newsgroup. Have by instance a look at
this message thread.

http://groups.google.com/group/micr...1513e34e83b/2d0b7be6bb0cf917#2d0b7be6bb0cf917


I hope this helps,

Cor

 

[CMM]

I got the impression that he was talking about ASP.NET (he mentioned
"pages")... in which case the UI ThreadException handler wouldn't be of
use... he would use the Application_Error event in Global.asax instead.

Personally, I usually just defer to customErrors - defaultRedirect in
Web.config. It depends on the requirements of the Web Application (usually a
"logging" requirement concern).

 

[tshad]

Tom,

It is as you wish, however if you want to do it more global, than is in my
idea the global exception handler better.

It is often handled by Jay in this newsgroup. Have by instance a look at
this message thread.

http://groups.google.com/group/micr...1513e34e83b/2d0b7be6bb0cf917#2d0b7be6bb0cf917


I hope this helps,

It does.

I got a lot of good ideas and information from everyone here.

Thanks,

Tom

 

[tshad]

I got the impression that he was talking about ASP.NET (he mentioned
"pages")... in which case the UI ThreadException handler wouldn't be of
use... he would use the Application_Error event in Global.asax instead.

I was and am using the Application_Error event.

Personally, I usually just defer to customErrors - defaultRedirect in
Web.config. It depends on the requirements of the Web Application (usually
a "logging" requirement concern).

This was something I was curious about. When would I use the Web.Config
redirect (CustomErrors) and when would I use Application_Error?

Can I use them both and if you can which one takes preference?

Thanks,

Tom