try/catch

Discussion in 'ASP .Net' started by tshad, Feb 8, 2006.

  1. tshad

    tshad Guest

    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
    tshad, Feb 8, 2006
    #1
    1. Advertising

  2. 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" <> wrote in message
    news:...
    > 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
    >
    Mark Fitzpatrick, Feb 9, 2006
    #2
    1. Advertising

  3. 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" <> wrote in message
    news:...
    > 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
    >
    Karl Seguin [MVP], Feb 9, 2006
    #3
  4. tshad

    Guest

    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" <> wrote in message
    news:...
    > 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
    >
    >

    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.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
    , Feb 12, 2006
    #4
  5. tshad

    tshad Guest

    <> wrote in message
    news:...
    >
    > 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" <> wrote in message
    > news:...
    >> 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
    >>
    >>

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

    >
    tshad, Feb 13, 2006
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. bienwell
    Replies:
    4
    Views:
    3,720
    bienwell
    May 27, 2005
  2. John Salerno
    Replies:
    20
    Views:
    828
    John Salerno
    Aug 11, 2006
  3. Fabio Z Tessitore

    who is simpler? try/except/else or try/except

    Fabio Z Tessitore, Aug 12, 2007, in forum: Python
    Replies:
    5
    Views:
    362
  4. =?Utf-8?B?QUo=?=

    When to TRY and not to TRY

    =?Utf-8?B?QUo=?=, Oct 16, 2007, in forum: ASP .Net
    Replies:
    2
    Views:
    320
    sloan
    Oct 17, 2007
  5. MRAB
    Replies:
    4
    Views:
    300
Loading...

Share This Page