Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > try/catch

Reply
Thread Tools

try/catch

 
 
tshad
Guest
Posts: n/a
 
      02-08-2006
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


 
Reply With Quote
 
 
 
 
Mark Fitzpatrick
Guest
Posts: n/a
 
      02-09-2006
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>



 
Reply With Quote
 
 
 
 
Karl Seguin [MVP]
Guest
Posts: n/a
 
      02-09-2006
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>



 
Reply With Quote
 
sloan@ipass.net
Guest
Posts: n/a
 
      02-12-2006

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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>
>

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.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


 
Reply With Quote
 
tshad
Guest
Posts: n/a
 
      02-13-2006
<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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
>>
>>

> 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.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

>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments