By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,699 Members | 1,218 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,699 IT Pros & Developers. It's quick & easy.

Try/Catch question

P: n/a
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.AppSet tings("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
Feb 9 '06 #1
Share this Question
Share on Google+
8 Replies


P: n/a
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
tshad wrote:
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.AppSe ttings("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

Feb 9 '06 #2

P: n/a
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
Feb 9 '06 #3

P: n/a
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.
Feb 9 '06 #4

P: n/a
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
Feb 9 '06 #5

P: n/a
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/micro...0b7be6bb0cf917
I hope this helps,

Cor
Feb 9 '06 #6

P: n/a
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).

--
-C. Moya
www.cmoya.com
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:OM**************@TK2MSFTNGP11.phx.gbl...
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/micro...0b7be6bb0cf917
I hope this helps,

Cor

Feb 9 '06 #7

P: n/a

"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:OM**************@TK2MSFTNGP11.phx.gbl...
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/micro...0b7be6bb0cf917
I hope this helps,
It does.

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

Thanks,

Tom
Cor

Feb 14 '06 #8

P: n/a
"CMM" <cm*@nospam.com> wrote in message
news:uo*************@TK2MSFTNGP12.phx.gbl...
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 --
-C. Moya
www.cmoya.com
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:OM**************@TK2MSFTNGP11.phx.gbl...
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/micro...0b7be6bb0cf917
I hope this helps,

Cor


Feb 14 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.