Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   ASP .Net (http://www.velocityreviews.com/forums/f29-asp-net.html)
-   -   try/finally with data access code (http://www.velocityreviews.com/forums/t76502-try-finally-with-data-access-code.html)

=?Utf-8?B?UmVwU3RhdA==?= 04-22-2004 03:51 PM

try/finally with data access code
 
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...

Bruno Jouhier [MVP] 04-22-2004 04:02 PM

Re: try/finally with data access code
 
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" <anonymous@discussions.microsoft.com> a écrit dans le message de
news:5D1BECE7-C51B-4769-9A44-A4926BE5864A@microsoft.com...
> 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 04-22-2004 07:43 PM

Re: try/finally with data access code
 
excellent, thanks!

"Bruno Jouhier [MVP]" <bjouhier@club-internet.fr> wrote in message
news:O6pLoMIKEHA.3184@TK2MSFTNGP10.phx.gbl...
> 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" <anonymous@discussions.microsoft.com> a écrit dans le message de
> news:5D1BECE7-C51B-4769-9A44-A4926BE5864A@microsoft.com...
> > 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 04-22-2004 09:30 PM

Re: try/finally with data access code
 
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" <anonymous@discussions.microsoft.com> wrote in message
news:5D1BECE7-C51B-4769-9A44-A4926BE5864A@microsoft.com...
> 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] 04-23-2004 07:32 AM

Re: try/finally with data access code
 
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]" <bjouhier@club-internet.fr> wrote in message
news:O6pLoMIKEHA.3184@TK2MSFTNGP10.phx.gbl...
> 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" <anonymous@discussions.microsoft.com> a écrit dans le message de
> news:5D1BECE7-C51B-4769-9A44-A4926BE5864A@microsoft.com...
> > 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] 04-23-2004 07:46 AM

Re: try/finally with data access code
 

"Angel Saenz-Badillos[MS]" <angelsa@online.microsoft.com> a écrit dans le
message de news:e2nwdUQKEHA.3704@TK2MSFTNGP11.phx.gbl...
> 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]" <bjouhier@club-internet.fr> wrote in message
> news:O6pLoMIKEHA.3184@TK2MSFTNGP10.phx.gbl...
> > 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" <anonymous@discussions.microsoft.com> a écrit dans le message

de
> > news:5D1BECE7-C51B-4769-9A44-A4926BE5864A@microsoft.com...
> > > 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 04-23-2004 10:54 AM

Re: try/finally with data access code
 
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]" <bjouhier@club-internet.fr> wrote in message
news:ubvqecQKEHA.1312@TK2MSFTNGP12.phx.gbl...
>
> "Angel Saenz-Badillos[MS]" <angelsa@online.microsoft.com> a écrit dans le
> message de news:e2nwdUQKEHA.3704@TK2MSFTNGP11.phx.gbl...
> > 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]" <bjouhier@club-internet.fr> wrote in message
> > news:O6pLoMIKEHA.3184@TK2MSFTNGP10.phx.gbl...
> > > 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" <anonymous@discussions.microsoft.com> a écrit dans le

message
> de
> > > news:5D1BECE7-C51B-4769-9A44-A4926BE5864A@microsoft.com...
> > > > 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] 04-23-2004 12:57 PM

Re: try/finally with data access code
 
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" <sorrytomuch@spam.com> a écrit dans le message de
news:%23RxmXFSKEHA.1156@TK2MSFTNGP09.phx.gbl...
> 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]" <bjouhier@club-internet.fr> wrote in message
> news:ubvqecQKEHA.1312@TK2MSFTNGP12.phx.gbl...
> >
> > "Angel Saenz-Badillos[MS]" <angelsa@online.microsoft.com> a écrit dans

le
> > message de news:e2nwdUQKEHA.3704@TK2MSFTNGP11.phx.gbl...
> > > 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]" <bjouhier@club-internet.fr> wrote in message
> > > news:O6pLoMIKEHA.3184@TK2MSFTNGP10.phx.gbl...
> > > > 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" <anonymous@discussions.microsoft.com> a écrit dans le

> message
> > de
> > > > news:5D1BECE7-C51B-4769-9A44-A4926BE5864A@microsoft.com...
> > > > > 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 04-23-2004 01:40 PM

Re: try/finally with data access code
 
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]" <bjouhier@club-internet.fr> wrote in message
news:#V9wdKTKEHA.1348@TK2MSFTNGP12.phx.gbl...
> 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" <sorrytomuch@spam.com> a écrit dans le message de
> news:%23RxmXFSKEHA.1156@TK2MSFTNGP09.phx.gbl...
> > 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]" <bjouhier@club-internet.fr> wrote in message
> > news:ubvqecQKEHA.1312@TK2MSFTNGP12.phx.gbl...
> > >
> > > "Angel Saenz-Badillos[MS]" <angelsa@online.microsoft.com> a écrit dans

> le
> > > message de news:e2nwdUQKEHA.3704@TK2MSFTNGP11.phx.gbl...
> > > > 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]" <bjouhier@club-internet.fr> wrote in message
> > > > news:O6pLoMIKEHA.3184@TK2MSFTNGP10.phx.gbl...
> > > > > 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" <anonymous@discussions.microsoft.com> a écrit dans le

> > message
> > > de
> > > > > news:5D1BECE7-C51B-4769-9A44-A4926BE5864A@microsoft.com...
> > > > > > 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] 04-23-2004 04:34 PM

Re: try/finally with data access code
 

"Marcel" <sorrytomuch@spam.com> a écrit dans le message de
news:eFyGDiTKEHA.2880@TK2MSFTNGP10.phx.gbl...
> 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]" <bjouhier@club-internet.fr> wrote in message
> news:#V9wdKTKEHA.1348@TK2MSFTNGP12.phx.gbl...
> > 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" <sorrytomuch@spam.com> a écrit dans le message de
> > news:%23RxmXFSKEHA.1156@TK2MSFTNGP09.phx.gbl...
> > > 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]" <bjouhier@club-internet.fr> wrote in message
> > > news:ubvqecQKEHA.1312@TK2MSFTNGP12.phx.gbl...
> > > >
> > > > "Angel Saenz-Badillos[MS]" <angelsa@online.microsoft.com> a écrit

dans
> > le
> > > > message de news:e2nwdUQKEHA.3704@TK2MSFTNGP11.phx.gbl...
> > > > > 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]" <bjouhier@club-internet.fr> wrote in message
> > > > > news:O6pLoMIKEHA.3184@TK2MSFTNGP10.phx.gbl...
> > > > > > 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" <anonymous@discussions.microsoft.com> a écrit dans le
> > > message
> > > > de
> > > > > > news:5D1BECE7-C51B-4769-9A44-A4926BE5864A@microsoft.com...
> > > > > > > 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...
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >

> >
> >

>
>





All times are GMT. The time now is 07:53 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.