What's wring with this try-catch block?

[HillBilly]

This is freaking me out. I'm using Membership and trying to determine if the
database is online. The GetConnectionSt ring( ) method returns a connection
string as expected but not when used in the try block.

I have the Open() and Close() methods commented out while using the
Response.Redire ct to test.
The code in the try block as shown will --never execute-- but the code in
the catch block --always executes-- whether the database is online or not.

WTF???

protected void LoginButton_Cli ck(object sender, EventArgs e)
{
// Redirect proves this test works
//Response.Redire ct(ResolveUrl(" ~/homepage.aspx?L oginButton_Clic k"));

SqlConnection testConnection = new
SqlConnection(G etConnectionStr ing("MyConnecti onString"));
if (!String.IsNull OrEmpty(testCon nection.ToStrin g()))
{
try
{
//testConnection. Open();
//testConnection. Close();
Response.Redire ct(ResolveUrl(" ~/homepage.aspx?M yConnectionStri ng-Found"));
}
catch (Exception ex)
{
Response.Redire ct(ResolveUrl(" ~/homepage.aspx?L oginButton_Clic k-Caught-Exception"));
}
}
}

[HillBilly]

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:MP******** *************@m snews.microsoft .com...

HillBilly <so******@somew here.comwrote:

Response.Redire ct works by setting something and then throwing an
exception (by default). If you look at the exception which is being
thrown, I susect you'll find it's a ThreadAbortExce ption. Look at the
documentation for Response.Redire ct for more information.

Aha! I'll certainly study that thank you but still, what do you do to
determine if the database is offline? I thought I'd convert the code into
a
method called before logging in or any other attempt to access the
database.
But if its not even online then what?

Trying to connect (and executing some basic operation) seems reasonable
to me - but unconnected to the problem you're seeing. I suggest you
extract the desired functionality (basically an "online/offline"
boolean check) into a separate method - that way you'll be catching
just the database exception there, rather than both the database
exception *and* the exception from the redirect.

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

I refactored as this implementation. ..

#region Method: IsDatabaseOffli ne()...
public void IsDatabaseOffli ne()
{
SqlConnection connection = new
SqlConnection(G etConnectionStr ing("MyConnecti onString"));
if (!String.IsNull OrEmpty(connect ion.ToString()) )
{
try
{
connection.Open ();
connection.Clos e();
connection.Disp ose();
}
catch (SqlException ex)
{
Response.Redire ct(ResolveUrl(" ~/ErrorPages/DatabaseError.a spx?Caught-SqlException")) ;
}
}
}
#endregion

You know I didn't even need the redirect in the try block but it sure taught
me a lesson in two ways. First, I've learned about ThreadAbortExce ption and
secondly I realized when the IsDatabaseOffli ne method is marked static it
causes an error because the SqlConnection object is not static which implies
all members of a static method must themselves be static.

More work to write the log and notification code but this should be muy
bueno for now eh?

[Jon Skeet [C# MVP]]

HillBilly <so******@somew here.comwrote:

I refactored as this implementation. ..

#region Method: IsDatabaseOffli ne()...
public void IsDatabaseOffli ne()
{
SqlConnection connection = new
SqlConnection(G etConnectionStr ing("MyConnecti onString"));
if (!String.IsNull OrEmpty(connect ion.ToString()) )
{
try
{
connection.Open ();
connection.Clos e();
connection.Disp ose();
}
catch (SqlException ex)
{
Response.Redire ct(ResolveUrl(" ~/ErrorPages/DatabaseError.a spx?Caught-SqlException")) ;
}
}
}
#endregion

No, that is still a bad thing in my view, for a few reasons:

1) You're mixing your database logic with your page logic. What if you
ever want to create a page with diagnostics of various things? Or use
this code for something other than a web page?

2) A method called "IsDatabaseOffl ine" really should return something.
Based on the method name I *certainly* wouldn't expect it to be
redirecting a response.

3) You should still use a "using" statement for the connection, IMO.
That way you don't need to explicitly close it or call Dispose (doing
both is reasonably pointless, btw) but you'll still close it if
something odd (like an asynchronous exception) happens after Open.

4) It may well be worth actually *doing* something with the connection
- something which forces it to try to talk to the database for real.
Otherwise you may find you've got stale connections which can be opened
and closed with no problems, but can't do any real work. I know that's
a problem with some connections on some platforms, but I don't know if
it's relevant in your particular situation.

You know I didn't even need the redirect in the try block but it sure taught
me a lesson in two ways. First, I've learned about ThreadAbortExce ption and
secondly I realized when the IsDatabaseOffli ne method is marked static it
causes an error because the SqlConnection object is not static which implies
all members of a static method must themselves be static.

The SqlConnection object is declared inside the method - it's
irrelevent. However, the Response property isn't static, and
GetConnectionSt ring may not be depending on what you're doing.

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[HillBilly]

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:MP******** *************@m snews.microsoft .com...

HillBilly <so******@somew here.comwrote:

>I refactored as this implementation. ..

#region Method: IsDatabaseOffli ne()...
public void IsDatabaseOffli ne()
{
SqlConnection connection = new
SqlConnection( GetConnectionSt ring("MyConnect ionString"));
if (!String.IsNull OrEmpty(connect ion.ToString()) )
{
try
{
connection.Open ();
connection.Clos e();
connection.Disp ose();
}
catch (SqlException ex)
{

Response.Redir ect(ResolveUrl( "~/ErrorPages/DatabaseError.a spx?Caught-SqlException")) ;
}
}
}
#endregion

No, that is still a bad thing in my view, for a few reasons:

1) You're mixing your database logic with your page logic. What if you
ever want to create a page with diagnostics of various things? Or use
this code for something other than a web page?

2) A method called "IsDatabaseOffl ine" really should return something.
Based on the method name I *certainly* wouldn't expect it to be
redirecting a response.

3) You should still use a "using" statement for the connection, IMO.
That way you don't need to explicitly close it or call Dispose (doing
both is reasonably pointless, btw) but you'll still close it if
something odd (like an asynchronous exception) happens after Open.

4) It may well be worth actually *doing* something with the connection
- something which forces it to try to talk to the database for real.
Otherwise you may find you've got stale connections which can be opened
and closed with no problems, but can't do any real work. I know that's
a problem with some connections on some platforms, but I don't know if
it's relevant in your particular situation.

>You know I didn't even need the redirect in the try block but it sure
taught
me a lesson in two ways. First, I've learned about ThreadAbortExce ption
and
secondly I realized when the IsDatabaseOffli ne method is marked static it
causes an error because the SqlConnection object is not static which
implies
all members of a static method must themselves be static.

The SqlConnection object is declared inside the method - it's
irrelevent. However, the Response property isn't static, and
GetConnectionSt ring may not be depending on what you're doing.

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

So when all is said and done I should not try to write superfluous code
worrying about the database being offline as that circumstance should and
would be caught with a SqlException anyway? And how is the exception cuaght
when using the 2.0 Login controls without rewriting authentication?

[Jon Skeet [C# MVP]]

HillBilly <so******@somew here.comwrote:

<snip>

So when all is said and done I should not try to write superfluous code
worrying about the database being offline as that circumstance should and
would be caught with a SqlException anyway?

Well, that's one option. But my point was mostly to separate out the
test for whether or not the database is online from what you happen to
want to do at the moment when the database is offline.

Write a simple method which tests for database connectivity and returns
the status (for the moment a simple bool would do) - and then act on
that return value. That's a much more flexible approach.

And how is the exception cuaght
when using the 2.0 Login controls without rewriting authentication?

No idea, I'm afraid. I'd ask on an ASP.NET group. Be aware that the
database could go offline after you do your check though, of course.

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[HillBilly]

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:MP******** *************@m snews.microsoft .com...

HillBilly <so******@somew here.comwrote:

<snip>

>So when all is said and done I should not try to write superfluous code
worrying about the database being offline as that circumstance should and
would be caught with a SqlException anyway?

Well, that's one option. But my point was mostly to separate out the
test for whether or not the database is online from what you happen to
want to do at the moment when the database is offline.

Write a simple method which tests for database connectivity and returns
the status (for the moment a simple bool would do) - and then act on
that return value. That's a much more flexible approach.

>And how is the exception cuaght
when using the 2.0 Login controls without rewriting authentication?

No idea, I'm afraid. I'd ask on an ASP.NET group. Be aware that the
database could go offline after you do your check though, of course.

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

Offline --after-- logging in? Gees that's a stunning thought ;-) so please,
one more comment if you would as I appreciate your attention. I thought --I
was writing a simple method-- which tests for database connectivity? I'm
asking myself how much simpler could it get than to start with the
connection which either is or isn't active and hence would fail and easily
be caught. The impetus to put it into a method I was thinking makes it
possible for reuse everywhere there is an initial request to access and use
the database as you said it yourself, "what happens when the database goes
offline afterwards?" And that can't be prevented by the web developer nor
caught in any way I can imagine.

Its not like I haven't studied the context of this issue looking all over
the place and there doesn't seem to be much of anything anywhere other than
our colleagues blogging or documenting SqlExceptions in general.

I'm going the route of writing more code. I mean what the hell. I'll only
learn yet more along the way. But you know what they say eh? All developers
are lazy so I just wanted to be like everybody else. :-)

[Jon Skeet [C# MVP]]

HillBilly <so******@somew here.comwrote:

Offline --after-- logging in?

That's one possibility. Another is that it goes offline *after* you've
tested connectivity, but *before* you've actually done the login.
Basically I'm saying that any test you do is stale immediately after
you've done it. That's not to say it's not worth doing, but just bear
the possibility in mind :)

so please, one more comment if you would as I appreciate your
attention. I thought --I was writing a simple method-- which tests
for database connectivity? I'm asking myself how much simpler could
it get than to start with the connection which either is or isn't
active and hence would fail and easily be caught.

Sounds reasonable to me.

The impetus to put it into a method I was thinking makes it possible
for reuse everywhere there is an initial request to access and use
the database as you said it yourself, "what happens when the database
goes offline afterwards?" And that can't be prevented by the web
developer nor caught in any way I can imagine.

Indeed. There's really not a lot you can do about it, other than be
aware of the remote possibility, and deal with it *reasonably*
gracefully (in particular, don't try to log the error to the
database!).

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[HillBilly]

<snip />
Thanks for hanging out Jon. Onward...