try/catch

[tshad]

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

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

Dim ConnectionStrin g as String
=System.Configu ration.Configur ationSettings.A ppSettings("MM_ CONNECTION_STRI NG_Connection")
Dim objConn as New SqlConnection (ConnectionStri ng)
Dim CommandText as String = "Select City,StateCode from zipCodes where
zipCode = @ZipCode and CityType = 'D'"
Dim objCmd as New SqlCommand(Comm andText,objConn )
with objCmd.Paramete rs
.Add("@ZipCode" ,SqlDbType.VarC har,9).value = ZipCode.Text
end with

try
objConn.Open()

dbReader = objCmd.ExecuteR eader

if dbReader.Read then
City.Text = dbReader("City" )
State.Text = dbReader("State Code")
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

[Mark Fitzpatrick]

Every try/catch has a performance hit. I try to use them sparingly. Users
don't necessarily need extremely detailed information. As a matter of
opinion, I don't want to give them extremely detailed information. If
something failed, such as retrieving records from a db, I want to tell them
that the process failed. I don't want to tell them that the application
couldn't find the database. That's something only I or one of the other
devs/administrators should learn about. You can still keep the user on the
page and have a single try/catch or a minimal number of them. Try/catches
are great for desktop applications, but on web applications they do slow
things up because you could have undreds or thousands of users executing the
page at once, meaning the performance hit by each try/catch is magnified
immensely. Bottom line, I try to discover the best coverage for each
try/catch so that I can trap the error and present information to the user
without going overboard.

Hope this helps,
Mark Fitzpatrick
Microsoft MVP - FrontPage
"tshad" <ts**********@f tsolutions.com> wrote in message
news:uG******** ******@TK2MSFTN GP10.phx.gbl...

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

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

Dim ConnectionStrin g as String
=System.Configu ration.Configur ationSettings.A ppSettings("MM_ CONNECTION_STRI NG_Connection")
Dim objConn as New SqlConnection (ConnectionStri ng)
Dim CommandText as String = "Select City,StateCode from zipCodes where
zipCode = @ZipCode and CityType = 'D'"
Dim objCmd as New SqlCommand(Comm andText,objConn )
with objCmd.Paramete rs
.Add("@ZipCode" ,SqlDbType.VarC har,9).value = ZipCode.Text
end with

try
objConn.Open()

dbReader = objCmd.ExecuteR eader

if dbReader.Read then
City.Text = dbReader("City" )
State.Text = dbReader("State Code")
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

[Karl Seguin [MVP]]

Straight from Mr Hejlsberg himself:
"No, because in a lot of cases, people don't care. They're not going to
handle any of these exceptions. There's a bottom level exception handler
around their message loop. That handler is just going to bring up a dialog
that says what went wrong and continue. The programmers protect their code
by writing try finally's everywhere, so they'll back out correctly if an
exception occurs, but they're not actually interested in handling the
exceptions.

....

In the finally, you protect yourself against the exceptions, but you don't
actually handle them. Error handling you put somewhere else. Surely in any
kind of event-driven application like any kind of modern UI, you typically
put an exception handler around your main message pump, and you just handle
exceptions as they fall out that way. But you make sure you protect yourself
all the way out by deallocating any resources you've grabbed, and so forth.
You clean up after yourself, so you're always in a consistent state. You
don't want a program where in 100 different places you handle exceptions and
pop up error dialogs. What if you want to change the way you put up that
dialog box? That's just terrible. The exception handling should be
centralized, and you should just protect yourself as the exceptions
propagate out to the handler."

Karl
--
http://www.openmymind.net/

"tshad" <ts**********@f tsolutions.com> wrote in message
news:uG******** ******@TK2MSFTN GP10.phx.gbl...

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

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

Dim ConnectionStrin g as String
=System.Configu ration.Configur ationSettings.A ppSettings("MM_ CONNECTION_STRI NG_Connection")
Dim objConn as New SqlConnection (ConnectionStri ng)
Dim CommandText as String = "Select City,StateCode from zipCodes where
zipCode = @ZipCode and CityType = 'D'"
Dim objCmd as New SqlCommand(Comm andText,objConn )
with objCmd.Paramete rs
.Add("@ZipCode" ,SqlDbType.VarC har,9).value = ZipCode.Text
end with

try
objConn.Open()

dbReader = objCmd.ExecuteR eader

if dbReader.Read then
City.Text = dbReader("City" )
State.Text = dbReader("State Code")
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

[sloan]

you actually want to have many many more

try{}
finally{}

blocks...

instead of

try{}
catch{Exception ex}

blocks.

search for "brad abrams", and you'll find some more info.


"tshad" <ts**********@f tsolutions.com> wrote in message
news:uG******** ******@TK2MSFTN GP10.phx.gbl...

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

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

Dim ConnectionStrin g as String
=System.Configu ration.Configur ationSettings.A ppSettings("MM_ CONNECTION_STRI NG_Connection")
Dim objConn as New SqlConnection (ConnectionStri ng)
Dim CommandText as String = "Select City,StateCode from zipCodes where
zipCode = @ZipCode and CityType = 'D'"
Dim objCmd as New SqlCommand(Comm andText,objConn )
with objCmd.Paramete rs
.Add("@ZipCode" ,SqlDbType.VarC har,9).value = ZipCode.Text
end with

try
objConn.Open()

dbReader = objCmd.ExecuteR eader

if dbReader.Read then
City.Text = dbReader("City" )
State.Text = dbReader("State Code")
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

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

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

Dim ConnectionStrin g as String
=System.Configu ration.Configur ationSettings.A ppSettings("MM_ CONNECTION_STRI NG_Connection")
Dim objConn as New SqlConnection (ConnectionStri ng)
Dim CommandText as String = "Select City,StateCode from zipCodes where
zipCode = @ZipCode and CityType = 'D'"
Dim objCmd as New SqlCommand(Comm andText,objConn )
with objCmd.Paramete rs
.Add("@ZipCode" ,SqlDbType.VarC har,9).value = ZipCode.Text
end with

try
objConn.Open()

dbReader = objCmd.ExecuteR eader

if dbReader.Read then
City.Text = dbReader("City" )
State.Text = dbReader("State Code")
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

[tshad]

<sl***@ipass.ne t> wrote in message
news:11******** **************@ g44g2000cwa.goo glegroups.com.. .

you actually want to have many many more

try{}
finally{}

blocks...

instead of

try{}
catch{Exception ex}

blocks.

search for "brad abrams", and you'll find some more info.
Found 'em.

Helps a lot.

Thanks,

Tom

"tshad" <ts**********@f tsolutions.com> wrote in message
news:uG******** ******@TK2MSFTN GP10.phx.gbl...

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

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

Dim ConnectionStrin g as String
=System.Configu ration.Configur ationSettings.A ppSettings("MM_ CONNECTION_STRI NG_Connection")
Dim objConn as New SqlConnection (ConnectionStri ng)
Dim CommandText as String = "Select City,StateCode from zipCodes where
zipCode = @ZipCode and CityType = 'D'"
Dim objCmd as New SqlCommand(Comm andText,objConn )
with objCmd.Paramete rs
.Add("@ZipCode" ,SqlDbType.VarC har,9).value = ZipCode.Text
end with

try
objConn.Open()

dbReader = objCmd.ExecuteR eader

if dbReader.Read then
City.Text = dbReader("City" )
State.Text = dbReader("State Code")
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

tshad wrote:

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

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

Dim ConnectionStrin g as String
=System.Configu ration.Configur ationSettings.A ppSettings("MM_ CONNECTION_STRI NG_Connection")
Dim objConn as New SqlConnection (ConnectionStri ng)
Dim CommandText as String = "Select City,StateCode from zipCodes where
zipCode = @ZipCode and CityType = 'D'"
Dim objCmd as New SqlCommand(Comm andText,objConn )
with objCmd.Paramete rs
.Add("@ZipCode" ,SqlDbType.VarC har,9).value = ZipCode.Text
end with

try
objConn.Open()

dbReader = objCmd.ExecuteR eader

if dbReader.Read then
City.Text = dbReader("City" )
State.Text = dbReader("State Code")
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