try/finally with data access code

Discussion in 'ASP .Net' started by =?Utf-8?B?UmVwU3RhdA==?=, Apr 22, 2004.

  1. If I have code such a

    SqConnection cndb = new SqlConnection(connstr)
    SqlDataReader dr = null
    tr

    cndb.Open()
    SqlCommand cmd = new SqlCommand("exec mysp", cndb)
    dr = cmd.ExecuteReader()

    catch (System.Exception e1) {Debug.WriteLine(e1.Message);
    finall

    if(dr != null) dr.Close()
    cndb.Close()


    what bugs me is that is there any possibility that dr would be non-null, but not open - when the finally block started - thus causing the lin
    if(dr != null) dr.Close()
    to fail, which would cause the cndb.Close() to never occur, leaving the connection open
    This is in an ASP.NET page
    Surely I don't have to put another try...finally within the first finally
    or is there some property I can use to check the state of it

    Thanks
    Any suggestions please...
     
    =?Utf-8?B?UmVwU3RhdA==?=, Apr 22, 2004
    #1
    1. Advertising

  2. No, dr cannot be null. ExecuteReader will throw an exception if it fails, it
    will not return null.

    You can simplify all this and rewrite it with the "using" statement because
    all the objects that you manipulate implement the IDisposable interface.
    Here is how I would rewrite this:

    using (SqlConnection cndb = new SqlConnection(connstr))
    {
    cndb.Open();
    using (SqlCommand cmd = new SqlCommand("exec mysp", cndb))
    {
    using (SqlDataReader dr = cmd.ExecuteReader())
    {
    // your stuff here
    }
    }
    }

    Also, unless you really want to log the exception at this level (you should
    return a status indicating that the operation failed), I would not catch the
    exception here? I would let it propagate upwards, until it reaches a
    "strategic" point in your code (or in the framework) where it will be logged
    and where the execution will resume.

    Bruno.

    "RepStat" <> a écrit dans le message de
    news:...
    > If I have code such as
    >
    > SqConnection cndb = new SqlConnection(connstr);
    > SqlDataReader dr = null;
    > try
    > {
    > cndb.Open();
    > SqlCommand cmd = new SqlCommand("exec mysp", cndb);
    > dr = cmd.ExecuteReader();
    > }
    > catch (System.Exception e1) {Debug.WriteLine(e1.Message);}
    > finally
    > {
    > if(dr != null) dr.Close();
    > cndb.Close();
    > }
    >
    > what bugs me is that is there any possibility that dr would be non-null,

    but not open - when the finally block started - thus causing the line
    > if(dr != null) dr.Close();
    > to fail, which would cause the cndb.Close() to never occur, leaving the

    connection open?
    > This is in an ASP.NET page.
    > Surely I don't have to put another try...finally within the first finally?
    > or is there some property I can use to check the state of it?
    >
    > Thanks!
    > Any suggestions please...
     
    Bruno Jouhier [MVP], Apr 22, 2004
    #2
    1. Advertising

  3. =?Utf-8?B?UmVwU3RhdA==?=

    Bonj Guest

    excellent, thanks!

    "Bruno Jouhier [MVP]" <> wrote in message
    news:...
    > No, dr cannot be null. ExecuteReader will throw an exception if it fails,

    it
    > will not return null.
    >
    > You can simplify all this and rewrite it with the "using" statement

    because
    > all the objects that you manipulate implement the IDisposable interface.
    > Here is how I would rewrite this:
    >
    > using (SqlConnection cndb = new SqlConnection(connstr))
    > {
    > cndb.Open();
    > using (SqlCommand cmd = new SqlCommand("exec mysp", cndb))
    > {
    > using (SqlDataReader dr = cmd.ExecuteReader())
    > {
    > // your stuff here
    > }
    > }
    > }
    >
    > Also, unless you really want to log the exception at this level (you

    should
    > return a status indicating that the operation failed), I would not catch

    the
    > exception here? I would let it propagate upwards, until it reaches a
    > "strategic" point in your code (or in the framework) where it will be

    logged
    > and where the execution will resume.
    >
    > Bruno.
    >
    > "RepStat" <> a écrit dans le message de
    > news:...
    > > If I have code such as
    > >
    > > SqConnection cndb = new SqlConnection(connstr);
    > > SqlDataReader dr = null;
    > > try
    > > {
    > > cndb.Open();
    > > SqlCommand cmd = new SqlCommand("exec mysp", cndb);
    > > dr = cmd.ExecuteReader();
    > > }
    > > catch (System.Exception e1) {Debug.WriteLine(e1.Message);}
    > > finally
    > > {
    > > if(dr != null) dr.Close();
    > > cndb.Close();
    > > }
    > >
    > > what bugs me is that is there any possibility that dr would be non-null,

    > but not open - when the finally block started - thus causing the line
    > > if(dr != null) dr.Close();
    > > to fail, which would cause the cndb.Close() to never occur, leaving the

    > connection open?
    > > This is in an ASP.NET page.
    > > Surely I don't have to put another try...finally within the first

    finally?
    > > or is there some property I can use to check the state of it?
    > >
    > > Thanks!
    > > Any suggestions please...

    >
    >
     
    Bonj, Apr 22, 2004
    #3
  4. =?Utf-8?B?UmVwU3RhdA==?=

    bruce barker Guest

    you can repeatable call Close on a closed (or never opened) reader or
    connection without error, so you need no more exception logic

    -- bruce (sqlwork.com)


    "RepStat" <> wrote in message
    news:...
    > If I have code such as
    >
    > SqConnection cndb = new SqlConnection(connstr);
    > SqlDataReader dr = null;
    > try
    > {
    > cndb.Open();
    > SqlCommand cmd = new SqlCommand("exec mysp", cndb);
    > dr = cmd.ExecuteReader();
    > }
    > catch (System.Exception e1) {Debug.WriteLine(e1.Message);}
    > finally
    > {
    > if(dr != null) dr.Close();
    > cndb.Close();
    > }
    >
    > what bugs me is that is there any possibility that dr would be non-null,

    but not open - when the finally block started - thus causing the line
    > if(dr != null) dr.Close();
    > to fail, which would cause the cndb.Close() to never occur, leaving the

    connection open?
    > This is in an ASP.NET page.
    > Surely I don't have to put another try...finally within the first finally?
    > or is there some property I can use to check the state of it?
    >
    > Thanks!
    > Any suggestions please...
     
    bruce barker, Apr 22, 2004
    #4
  5. This definitely gets my vote <g> when I think of all the trouble we could
    have saved if we had written the docs in this fashion...
    Unfortunately VB.net does not support the using construct and it still
    requires try finally blocks.

    Just one comment:
    > I would let it propagate upwards, until it reaches a
    > "strategic" point in your code (or in the framework)


    Please not in the framework!
    --
    Angel Saenz-Badillos [MS] Managed Providers
    This posting is provided "AS IS", with no warranties, and confers no
    rights.Please do not send email directly to this alias.
    This alias is for newsgroup purposes only.


    "Bruno Jouhier [MVP]" <> wrote in message
    news:...
    > No, dr cannot be null. ExecuteReader will throw an exception if it fails,

    it
    > will not return null.
    >
    > You can simplify all this and rewrite it with the "using" statement

    because
    > all the objects that you manipulate implement the IDisposable interface.
    > Here is how I would rewrite this:
    >
    > using (SqlConnection cndb = new SqlConnection(connstr))
    > {
    > cndb.Open();
    > using (SqlCommand cmd = new SqlCommand("exec mysp", cndb))
    > {
    > using (SqlDataReader dr = cmd.ExecuteReader())
    > {
    > // your stuff here
    > }
    > }
    > }
    >
    > Also, unless you really want to log the exception at this level (you

    should
    > return a status indicating that the operation failed), I would not catch

    the
    > exception here? I would let it propagate upwards, until it reaches a
    > "strategic" point in your code (or in the framework) where it will be

    logged
    > and where the execution will resume.
    >
    > Bruno.
    >
    > "RepStat" <> a écrit dans le message de
    > news:...
    > > If I have code such as
    > >
    > > SqConnection cndb = new SqlConnection(connstr);
    > > SqlDataReader dr = null;
    > > try
    > > {
    > > cndb.Open();
    > > SqlCommand cmd = new SqlCommand("exec mysp", cndb);
    > > dr = cmd.ExecuteReader();
    > > }
    > > catch (System.Exception e1) {Debug.WriteLine(e1.Message);}
    > > finally
    > > {
    > > if(dr != null) dr.Close();
    > > cndb.Close();
    > > }
    > >
    > > what bugs me is that is there any possibility that dr would be non-null,

    > but not open - when the finally block started - thus causing the line
    > > if(dr != null) dr.Close();
    > > to fail, which would cause the cndb.Close() to never occur, leaving the

    > connection open?
    > > This is in an ASP.NET page.
    > > Surely I don't have to put another try...finally within the first

    finally?
    > > or is there some property I can use to check the state of it?
    > >
    > > Thanks!
    > > Any suggestions please...

    >
    >
     
    Angel Saenz-Badillos[MS], Apr 23, 2004
    #5
  6. "Angel Saenz-Badillos[MS]" <> a écrit dans le
    message de news:...
    > This definitely gets my vote <g> when I think of all the trouble we could
    > have saved if we had written the docs in this fashion...
    > Unfortunately VB.net does not support the using construct and it still
    > requires try finally blocks.
    >
    > Just one comment:
    > > I would let it propagate upwards, until it reaches a
    > > "strategic" point in your code (or in the framework)

    >
    > Please not in the framework!


    Why not? In a WinForms app, if you do not catch exceptions in your event
    handlers, the exceptions ends up being caught by the framework, which
    triggers a ThreadException event. The default dialog box that the framework
    displays is not the one I would like to see in a real application (I don't
    want to give the option to kill the application, at least not in such a
    visible way). So, the easiest way to handle all these exceptions it to let
    the framework catch them and to associate a custom error dialog to the
    ThreadException event. This way, you are sure that all exceptions will be
    handled and reported in a consistent way.

    There is one pitfall with this scheme, though: it does not work when the
    application is run from the debugger, probably because the debugger
    short-circuits the ThreadException event. This is a pain because the
    application dies on the first exception when you run it from the debugger.
    On the other hand, it works great when the application is run normally.

    Bruno.
    > --
    > Angel Saenz-Badillos [MS] Managed Providers
    > This posting is provided "AS IS", with no warranties, and confers no
    > rights.Please do not send email directly to this alias.
    > This alias is for newsgroup purposes only.
    >
    >
    > "Bruno Jouhier [MVP]" <> wrote in message
    > news:...
    > > No, dr cannot be null. ExecuteReader will throw an exception if it

    fails,
    > it
    > > will not return null.
    > >
    > > You can simplify all this and rewrite it with the "using" statement

    > because
    > > all the objects that you manipulate implement the IDisposable interface.
    > > Here is how I would rewrite this:
    > >
    > > using (SqlConnection cndb = new SqlConnection(connstr))
    > > {
    > > cndb.Open();
    > > using (SqlCommand cmd = new SqlCommand("exec mysp", cndb))
    > > {
    > > using (SqlDataReader dr = cmd.ExecuteReader())
    > > {
    > > // your stuff here
    > > }
    > > }
    > > }
    > >
    > > Also, unless you really want to log the exception at this level (you

    > should
    > > return a status indicating that the operation failed), I would not catch

    > the
    > > exception here? I would let it propagate upwards, until it reaches a
    > > "strategic" point in your code (or in the framework) where it will be

    > logged
    > > and where the execution will resume.
    > >
    > > Bruno.
    > >
    > > "RepStat" <> a écrit dans le message

    de
    > > news:...
    > > > If I have code such as
    > > >
    > > > SqConnection cndb = new SqlConnection(connstr);
    > > > SqlDataReader dr = null;
    > > > try
    > > > {
    > > > cndb.Open();
    > > > SqlCommand cmd = new SqlCommand("exec mysp", cndb);
    > > > dr = cmd.ExecuteReader();
    > > > }
    > > > catch (System.Exception e1) {Debug.WriteLine(e1.Message);}
    > > > finally
    > > > {
    > > > if(dr != null) dr.Close();
    > > > cndb.Close();
    > > > }
    > > >
    > > > what bugs me is that is there any possibility that dr would be

    non-null,
    > > but not open - when the finally block started - thus causing the line
    > > > if(dr != null) dr.Close();
    > > > to fail, which would cause the cndb.Close() to never occur, leaving

    the
    > > connection open?
    > > > This is in an ASP.NET page.
    > > > Surely I don't have to put another try...finally within the first

    > finally?
    > > > or is there some property I can use to check the state of it?
    > > >
    > > > Thanks!
    > > > Any suggestions please...

    > >
    > >

    >
    >
     
    Bruno Jouhier [MVP], Apr 23, 2004
    #6
  7. =?Utf-8?B?UmVwU3RhdA==?=

    Marcel Guest

    Bruno,

    Can you give an example of how to catch the ThreadExeption? I want to use it
    for any exeptions I fail to catch.
    Will USING be in VB.NET 2005?

    Marcel

    "Bruno Jouhier [MVP]" <> wrote in message
    news:...
    >
    > "Angel Saenz-Badillos[MS]" <> a écrit dans le
    > message de news:...
    > > This definitely gets my vote <g> when I think of all the trouble we

    could
    > > have saved if we had written the docs in this fashion...
    > > Unfortunately VB.net does not support the using construct and it still
    > > requires try finally blocks.
    > >
    > > Just one comment:
    > > > I would let it propagate upwards, until it reaches a
    > > > "strategic" point in your code (or in the framework)

    > >
    > > Please not in the framework!

    >
    > Why not? In a WinForms app, if you do not catch exceptions in your event
    > handlers, the exceptions ends up being caught by the framework, which
    > triggers a ThreadException event. The default dialog box that the

    framework
    > displays is not the one I would like to see in a real application (I don't
    > want to give the option to kill the application, at least not in such a
    > visible way). So, the easiest way to handle all these exceptions it to let
    > the framework catch them and to associate a custom error dialog to the
    > ThreadException event. This way, you are sure that all exceptions will be
    > handled and reported in a consistent way.
    >
    > There is one pitfall with this scheme, though: it does not work when the
    > application is run from the debugger, probably because the debugger
    > short-circuits the ThreadException event. This is a pain because the
    > application dies on the first exception when you run it from the debugger.
    > On the other hand, it works great when the application is run normally.
    >
    > Bruno.
    > > --
    > > Angel Saenz-Badillos [MS] Managed Providers
    > > This posting is provided "AS IS", with no warranties, and confers no
    > > rights.Please do not send email directly to this alias.
    > > This alias is for newsgroup purposes only.
    > >
    > >
    > > "Bruno Jouhier [MVP]" <> wrote in message
    > > news:...
    > > > No, dr cannot be null. ExecuteReader will throw an exception if it

    > fails,
    > > it
    > > > will not return null.
    > > >
    > > > You can simplify all this and rewrite it with the "using" statement

    > > because
    > > > all the objects that you manipulate implement the IDisposable

    interface.
    > > > Here is how I would rewrite this:
    > > >
    > > > using (SqlConnection cndb = new SqlConnection(connstr))
    > > > {
    > > > cndb.Open();
    > > > using (SqlCommand cmd = new SqlCommand("exec mysp", cndb))
    > > > {
    > > > using (SqlDataReader dr = cmd.ExecuteReader())
    > > > {
    > > > // your stuff here
    > > > }
    > > > }
    > > > }
    > > >
    > > > Also, unless you really want to log the exception at this level (you

    > > should
    > > > return a status indicating that the operation failed), I would not

    catch
    > > the
    > > > exception here? I would let it propagate upwards, until it reaches a
    > > > "strategic" point in your code (or in the framework) where it will be

    > > logged
    > > > and where the execution will resume.
    > > >
    > > > Bruno.
    > > >
    > > > "RepStat" <> a écrit dans le

    message
    > de
    > > > news:...
    > > > > If I have code such as
    > > > >
    > > > > SqConnection cndb = new SqlConnection(connstr);
    > > > > SqlDataReader dr = null;
    > > > > try
    > > > > {
    > > > > cndb.Open();
    > > > > SqlCommand cmd = new SqlCommand("exec mysp", cndb);
    > > > > dr = cmd.ExecuteReader();
    > > > > }
    > > > > catch (System.Exception e1) {Debug.WriteLine(e1.Message);}
    > > > > finally
    > > > > {
    > > > > if(dr != null) dr.Close();
    > > > > cndb.Close();
    > > > > }
    > > > >
    > > > > what bugs me is that is there any possibility that dr would be

    > non-null,
    > > > but not open - when the finally block started - thus causing the line
    > > > > if(dr != null) dr.Close();
    > > > > to fail, which would cause the cndb.Close() to never occur, leaving

    > the
    > > > connection open?
    > > > > This is in an ASP.NET page.
    > > > > Surely I don't have to put another try...finally within the first

    > > finally?
    > > > > or is there some property I can use to check the state of it?
    > > > >
    > > > > Thanks!
    > > > > Any suggestions please...
    > > >
    > > >

    > >
    > >

    >
    >
     
    Marcel, Apr 23, 2004
    #7
  8. This is not an exception but an event sent by the framework. The syntax is:

    Application.Exception += new ThreadExceptionEventHandler(exceptionProc);

    Sorry, this is C#, I let you translate to VB because I am not fluent in VB
    and I will probably mess it up.

    You can take a look at the doc page on Application.ThreadException for more
    details (and a VB example).

    I am beta testing VS 2005 but I am only testing the J# and C# stuff. So, I
    let someone else answer the VB question about "using". Seems to me that VB
    should also support this very nice feature.

    Bruno.

    "Marcel" <> a écrit dans le message de
    news:%...
    > Bruno,
    >
    > Can you give an example of how to catch the ThreadExeption? I want to use

    it
    > for any exeptions I fail to catch.
    > Will USING be in VB.NET 2005?
    >
    > Marcel
    >
    > "Bruno Jouhier [MVP]" <> wrote in message
    > news:...
    > >
    > > "Angel Saenz-Badillos[MS]" <> a écrit dans

    le
    > > message de news:...
    > > > This definitely gets my vote <g> when I think of all the trouble we

    > could
    > > > have saved if we had written the docs in this fashion...
    > > > Unfortunately VB.net does not support the using construct and it still
    > > > requires try finally blocks.
    > > >
    > > > Just one comment:
    > > > > I would let it propagate upwards, until it reaches a
    > > > > "strategic" point in your code (or in the framework)
    > > >
    > > > Please not in the framework!

    > >
    > > Why not? In a WinForms app, if you do not catch exceptions in your event
    > > handlers, the exceptions ends up being caught by the framework, which
    > > triggers a ThreadException event. The default dialog box that the

    > framework
    > > displays is not the one I would like to see in a real application (I

    don't
    > > want to give the option to kill the application, at least not in such a
    > > visible way). So, the easiest way to handle all these exceptions it to

    let
    > > the framework catch them and to associate a custom error dialog to the
    > > ThreadException event. This way, you are sure that all exceptions will

    be
    > > handled and reported in a consistent way.
    > >
    > > There is one pitfall with this scheme, though: it does not work when the
    > > application is run from the debugger, probably because the debugger
    > > short-circuits the ThreadException event. This is a pain because the
    > > application dies on the first exception when you run it from the

    debugger.
    > > On the other hand, it works great when the application is run normally.
    > >
    > > Bruno.
    > > > --
    > > > Angel Saenz-Badillos [MS] Managed Providers
    > > > This posting is provided "AS IS", with no warranties, and confers no
    > > > rights.Please do not send email directly to this alias.
    > > > This alias is for newsgroup purposes only.
    > > >
    > > >
    > > > "Bruno Jouhier [MVP]" <> wrote in message
    > > > news:...
    > > > > No, dr cannot be null. ExecuteReader will throw an exception if it

    > > fails,
    > > > it
    > > > > will not return null.
    > > > >
    > > > > You can simplify all this and rewrite it with the "using" statement
    > > > because
    > > > > all the objects that you manipulate implement the IDisposable

    > interface.
    > > > > Here is how I would rewrite this:
    > > > >
    > > > > using (SqlConnection cndb = new SqlConnection(connstr))
    > > > > {
    > > > > cndb.Open();
    > > > > using (SqlCommand cmd = new SqlCommand("exec mysp", cndb))
    > > > > {
    > > > > using (SqlDataReader dr = cmd.ExecuteReader())
    > > > > {
    > > > > // your stuff here
    > > > > }
    > > > > }
    > > > > }
    > > > >
    > > > > Also, unless you really want to log the exception at this level (you
    > > > should
    > > > > return a status indicating that the operation failed), I would not

    > catch
    > > > the
    > > > > exception here? I would let it propagate upwards, until it reaches a
    > > > > "strategic" point in your code (or in the framework) where it will

    be
    > > > logged
    > > > > and where the execution will resume.
    > > > >
    > > > > Bruno.
    > > > >
    > > > > "RepStat" <> a écrit dans le

    > message
    > > de
    > > > > news:...
    > > > > > If I have code such as
    > > > > >
    > > > > > SqConnection cndb = new SqlConnection(connstr);
    > > > > > SqlDataReader dr = null;
    > > > > > try
    > > > > > {
    > > > > > cndb.Open();
    > > > > > SqlCommand cmd = new SqlCommand("exec mysp", cndb);
    > > > > > dr = cmd.ExecuteReader();
    > > > > > }
    > > > > > catch (System.Exception e1) {Debug.WriteLine(e1.Message);}
    > > > > > finally
    > > > > > {
    > > > > > if(dr != null) dr.Close();
    > > > > > cndb.Close();
    > > > > > }
    > > > > >
    > > > > > what bugs me is that is there any possibility that dr would be

    > > non-null,
    > > > > but not open - when the finally block started - thus causing the

    line
    > > > > > if(dr != null) dr.Close();
    > > > > > to fail, which would cause the cndb.Close() to never occur,

    leaving
    > > the
    > > > > connection open?
    > > > > > This is in an ASP.NET page.
    > > > > > Surely I don't have to put another try...finally within the first
    > > > finally?
    > > > > > or is there some property I can use to check the state of it?
    > > > > >
    > > > > > Thanks!
    > > > > > Any suggestions please...
    > > > >
    > > > >
    > > >
    > > >

    > >
    > >

    >
    >
     
    Bruno Jouhier [MVP], Apr 23, 2004
    #8
  9. =?Utf-8?B?UmVwU3RhdA==?=

    Marcel Guest

    Thnx, does this event gets fired for all exceptions that are not catched by
    your own code?

    I don't have the beta version so i cannot find out for myself...

    Marcel

    "Bruno Jouhier [MVP]" <> wrote in message
    news:#...
    > This is not an exception but an event sent by the framework. The syntax

    is:
    >
    > Application.Exception += new ThreadExceptionEventHandler(exceptionProc);
    >
    > Sorry, this is C#, I let you translate to VB because I am not fluent in VB
    > and I will probably mess it up.
    >
    > You can take a look at the doc page on Application.ThreadException for

    more
    > details (and a VB example).
    >
    > I am beta testing VS 2005 but I am only testing the J# and C# stuff. So, I
    > let someone else answer the VB question about "using". Seems to me that VB
    > should also support this very nice feature.
    >
    > Bruno.
    >
    > "Marcel" <> a écrit dans le message de
    > news:%...
    > > Bruno,
    > >
    > > Can you give an example of how to catch the ThreadExeption? I want to

    use
    > it
    > > for any exeptions I fail to catch.
    > > Will USING be in VB.NET 2005?
    > >
    > > Marcel
    > >
    > > "Bruno Jouhier [MVP]" <> wrote in message
    > > news:...
    > > >
    > > > "Angel Saenz-Badillos[MS]" <> a écrit dans

    > le
    > > > message de news:...
    > > > > This definitely gets my vote <g> when I think of all the trouble we

    > > could
    > > > > have saved if we had written the docs in this fashion...
    > > > > Unfortunately VB.net does not support the using construct and it

    still
    > > > > requires try finally blocks.
    > > > >
    > > > > Just one comment:
    > > > > > I would let it propagate upwards, until it reaches a
    > > > > > "strategic" point in your code (or in the framework)
    > > > >
    > > > > Please not in the framework!
    > > >
    > > > Why not? In a WinForms app, if you do not catch exceptions in your

    event
    > > > handlers, the exceptions ends up being caught by the framework, which
    > > > triggers a ThreadException event. The default dialog box that the

    > > framework
    > > > displays is not the one I would like to see in a real application (I

    > don't
    > > > want to give the option to kill the application, at least not in such

    a
    > > > visible way). So, the easiest way to handle all these exceptions it to

    > let
    > > > the framework catch them and to associate a custom error dialog to the
    > > > ThreadException event. This way, you are sure that all exceptions will

    > be
    > > > handled and reported in a consistent way.
    > > >
    > > > There is one pitfall with this scheme, though: it does not work when

    the
    > > > application is run from the debugger, probably because the debugger
    > > > short-circuits the ThreadException event. This is a pain because the
    > > > application dies on the first exception when you run it from the

    > debugger.
    > > > On the other hand, it works great when the application is run

    normally.
    > > >
    > > > Bruno.
    > > > > --
    > > > > Angel Saenz-Badillos [MS] Managed Providers
    > > > > This posting is provided "AS IS", with no warranties, and confers no
    > > > > rights.Please do not send email directly to this alias.
    > > > > This alias is for newsgroup purposes only.
    > > > >
    > > > >
    > > > > "Bruno Jouhier [MVP]" <> wrote in message
    > > > > news:...
    > > > > > No, dr cannot be null. ExecuteReader will throw an exception if it
    > > > fails,
    > > > > it
    > > > > > will not return null.
    > > > > >
    > > > > > You can simplify all this and rewrite it with the "using"

    statement
    > > > > because
    > > > > > all the objects that you manipulate implement the IDisposable

    > > interface.
    > > > > > Here is how I would rewrite this:
    > > > > >
    > > > > > using (SqlConnection cndb = new SqlConnection(connstr))
    > > > > > {
    > > > > > cndb.Open();
    > > > > > using (SqlCommand cmd = new SqlCommand("exec mysp", cndb))
    > > > > > {
    > > > > > using (SqlDataReader dr = cmd.ExecuteReader())
    > > > > > {
    > > > > > // your stuff here
    > > > > > }
    > > > > > }
    > > > > > }
    > > > > >
    > > > > > Also, unless you really want to log the exception at this level

    (you
    > > > > should
    > > > > > return a status indicating that the operation failed), I would not

    > > catch
    > > > > the
    > > > > > exception here? I would let it propagate upwards, until it reaches

    a
    > > > > > "strategic" point in your code (or in the framework) where it will

    > be
    > > > > logged
    > > > > > and where the execution will resume.
    > > > > >
    > > > > > Bruno.
    > > > > >
    > > > > > "RepStat" <> a écrit dans le

    > > message
    > > > de
    > > > > > news:...
    > > > > > > If I have code such as
    > > > > > >
    > > > > > > SqConnection cndb = new SqlConnection(connstr);
    > > > > > > SqlDataReader dr = null;
    > > > > > > try
    > > > > > > {
    > > > > > > cndb.Open();
    > > > > > > SqlCommand cmd = new SqlCommand("exec mysp", cndb);
    > > > > > > dr = cmd.ExecuteReader();
    > > > > > > }
    > > > > > > catch (System.Exception e1) {Debug.WriteLine(e1.Message);}
    > > > > > > finally
    > > > > > > {
    > > > > > > if(dr != null) dr.Close();
    > > > > > > cndb.Close();
    > > > > > > }
    > > > > > >
    > > > > > > what bugs me is that is there any possibility that dr would be
    > > > non-null,
    > > > > > but not open - when the finally block started - thus causing the

    > line
    > > > > > > if(dr != null) dr.Close();
    > > > > > > to fail, which would cause the cndb.Close() to never occur,

    > leaving
    > > > the
    > > > > > connection open?
    > > > > > > This is in an ASP.NET page.
    > > > > > > Surely I don't have to put another try...finally within the

    first
    > > > > finally?
    > > > > > > or is there some property I can use to check the state of it?
    > > > > > >
    > > > > > > Thanks!
    > > > > > > Any suggestions please...
    > > > > >
    > > > > >
    > > > >
    > > > >
    > > >
    > > >

    > >
    > >

    >
    >
     
    Marcel, Apr 23, 2004
    #9
  10. "Marcel" <> a écrit dans le message de
    news:...
    > Thnx, does this event gets fired for all exceptions that are not catched

    by
    > your own code?


    I think so and so far it has worked this way. There is just one caveeat, as
    I said in an earlier message: it won't work when your run your application
    from the debugger, you have to run it "normally".

    >
    > I don't have the beta version so i cannot find out for myself...
    >
    > Marcel
    >
    > "Bruno Jouhier [MVP]" <> wrote in message
    > news:#...
    > > This is not an exception but an event sent by the framework. The syntax

    > is:
    > >
    > > Application.Exception += new ThreadExceptionEventHandler(exceptionProc);
    > >
    > > Sorry, this is C#, I let you translate to VB because I am not fluent in

    VB
    > > and I will probably mess it up.
    > >
    > > You can take a look at the doc page on Application.ThreadException for

    > more
    > > details (and a VB example).
    > >
    > > I am beta testing VS 2005 but I am only testing the J# and C# stuff. So,

    I
    > > let someone else answer the VB question about "using". Seems to me that

    VB
    > > should also support this very nice feature.
    > >
    > > Bruno.
    > >
    > > "Marcel" <> a écrit dans le message de
    > > news:%...
    > > > Bruno,
    > > >
    > > > Can you give an example of how to catch the ThreadExeption? I want to

    > use
    > > it
    > > > for any exeptions I fail to catch.
    > > > Will USING be in VB.NET 2005?
    > > >
    > > > Marcel
    > > >
    > > > "Bruno Jouhier [MVP]" <> wrote in message
    > > > news:...
    > > > >
    > > > > "Angel Saenz-Badillos[MS]" <> a écrit

    dans
    > > le
    > > > > message de news:...
    > > > > > This definitely gets my vote <g> when I think of all the trouble

    we
    > > > could
    > > > > > have saved if we had written the docs in this fashion...
    > > > > > Unfortunately VB.net does not support the using construct and it

    > still
    > > > > > requires try finally blocks.
    > > > > >
    > > > > > Just one comment:
    > > > > > > I would let it propagate upwards, until it reaches a
    > > > > > > "strategic" point in your code (or in the framework)
    > > > > >
    > > > > > Please not in the framework!
    > > > >
    > > > > Why not? In a WinForms app, if you do not catch exceptions in your

    > event
    > > > > handlers, the exceptions ends up being caught by the framework,

    which
    > > > > triggers a ThreadException event. The default dialog box that the
    > > > framework
    > > > > displays is not the one I would like to see in a real application (I

    > > don't
    > > > > want to give the option to kill the application, at least not in

    such
    > a
    > > > > visible way). So, the easiest way to handle all these exceptions it

    to
    > > let
    > > > > the framework catch them and to associate a custom error dialog to

    the
    > > > > ThreadException event. This way, you are sure that all exceptions

    will
    > > be
    > > > > handled and reported in a consistent way.
    > > > >
    > > > > There is one pitfall with this scheme, though: it does not work when

    > the
    > > > > application is run from the debugger, probably because the debugger
    > > > > short-circuits the ThreadException event. This is a pain because the
    > > > > application dies on the first exception when you run it from the

    > > debugger.
    > > > > On the other hand, it works great when the application is run

    > normally.
    > > > >
    > > > > Bruno.
    > > > > > --
    > > > > > Angel Saenz-Badillos [MS] Managed Providers
    > > > > > This posting is provided "AS IS", with no warranties, and confers

    no
    > > > > > rights.Please do not send email directly to this alias.
    > > > > > This alias is for newsgroup purposes only.
    > > > > >
    > > > > >
    > > > > > "Bruno Jouhier [MVP]" <> wrote in message
    > > > > > news:...
    > > > > > > No, dr cannot be null. ExecuteReader will throw an exception if

    it
    > > > > fails,
    > > > > > it
    > > > > > > will not return null.
    > > > > > >
    > > > > > > You can simplify all this and rewrite it with the "using"

    > statement
    > > > > > because
    > > > > > > all the objects that you manipulate implement the IDisposable
    > > > interface.
    > > > > > > Here is how I would rewrite this:
    > > > > > >
    > > > > > > using (SqlConnection cndb = new SqlConnection(connstr))
    > > > > > > {
    > > > > > > cndb.Open();
    > > > > > > using (SqlCommand cmd = new SqlCommand("exec mysp", cndb))
    > > > > > > {
    > > > > > > using (SqlDataReader dr = cmd.ExecuteReader())
    > > > > > > {
    > > > > > > // your stuff here
    > > > > > > }
    > > > > > > }
    > > > > > > }
    > > > > > >
    > > > > > > Also, unless you really want to log the exception at this level

    > (you
    > > > > > should
    > > > > > > return a status indicating that the operation failed), I would

    not
    > > > catch
    > > > > > the
    > > > > > > exception here? I would let it propagate upwards, until it

    reaches
    > a
    > > > > > > "strategic" point in your code (or in the framework) where it

    will
    > > be
    > > > > > logged
    > > > > > > and where the execution will resume.
    > > > > > >
    > > > > > > Bruno.
    > > > > > >
    > > > > > > "RepStat" <> a écrit dans le
    > > > message
    > > > > de
    > > > > > > news:...
    > > > > > > > If I have code such as
    > > > > > > >
    > > > > > > > SqConnection cndb = new SqlConnection(connstr);
    > > > > > > > SqlDataReader dr = null;
    > > > > > > > try
    > > > > > > > {
    > > > > > > > cndb.Open();
    > > > > > > > SqlCommand cmd = new SqlCommand("exec mysp", cndb);
    > > > > > > > dr = cmd.ExecuteReader();
    > > > > > > > }
    > > > > > > > catch (System.Exception e1) {Debug.WriteLine(e1.Message);}
    > > > > > > > finally
    > > > > > > > {
    > > > > > > > if(dr != null) dr.Close();
    > > > > > > > cndb.Close();
    > > > > > > > }
    > > > > > > >
    > > > > > > > what bugs me is that is there any possibility that dr would be
    > > > > non-null,
    > > > > > > but not open - when the finally block started - thus causing the

    > > line
    > > > > > > > if(dr != null) dr.Close();
    > > > > > > > to fail, which would cause the cndb.Close() to never occur,

    > > leaving
    > > > > the
    > > > > > > connection open?
    > > > > > > > This is in an ASP.NET page.
    > > > > > > > Surely I don't have to put another try...finally within the

    > first
    > > > > > finally?
    > > > > > > > or is there some property I can use to check the state of it?
    > > > > > > >
    > > > > > > > Thanks!
    > > > > > > > Any suggestions please...
    > > > > > >
    > > > > > >
    > > > > >
    > > > > >
    > > > >
    > > > >
    > > >
    > > >

    > >
    > >

    >
    >
     
    Bruno Jouhier [MVP], Apr 23, 2004
    #10
    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. VB Programmer

    Question: Try,Catch,Finally

    VB Programmer, Aug 7, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    382
    Kevin Spencer
    Aug 7, 2003
  2. VB Programmer

    The problem with Try Catch Finally...

    VB Programmer, Aug 12, 2003, in forum: ASP .Net
    Replies:
    23
    Views:
    790
    Chad Myers
    Aug 15, 2003
  3. localhost
    Replies:
    1
    Views:
    397
    Steven Cheng[MSFT]
    Dec 25, 2003
  4. djw
    Replies:
    1
    Views:
    367
    Michael Hoffman
    Mar 8, 2005
  5. David Lozzi

    Try...Catch...Finally not firing finally?

    David Lozzi, Apr 23, 2007, in forum: ASP .Net
    Replies:
    12
    Views:
    821
    Alvin Bruney [MVP]
    May 11, 2007
Loading...

Share This Page