Handling exceptions

[Cor Ligthert[MVP]]

Arne,

Did you see my msdn link about the SQLException and how will you get from
the server any information as you have not even a cable to it?

Cor

 

[Cor Ligthert[MVP]]

(a lot snipped)

How is a broken network connection a design time error? *Handling* the
broken network connection is a design-time issue. A program cannot
predict, prevent or flawlessly detect a broken network connection, no
matter how hard it tries. Sometimes things just go wrong as you're doing
them. Signaling that we unexpectedly cannot complete an operation is what
exceptions are *for*. Stress "unexpectedly".

How can an SQLException be given back by a Server that is not connected with
your client.?

http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlexception.aspx

What on earth is "catching with the normal exception"? Do you mean a
catch-all exception handler for "things went wrong"?

http://msdn.microsoft.com/en-us/library/system.exception.aspx

Cor

 

[Jeroen Mostert]

(a lot snipped)
How can an SQLException be given back by a Server that is not connected
with your client.?

An SQLException is never "given back by a server", it's raised by a class
implementing database functionality. In some cases, the SQLException
represents an error condition indicated by the server. In other cases, it
represents an error condition detected independently from the server (being
unable to connect would be one).

Surely I'm not divulging some secret here, so I can't help but wonder what
you're getting at.

 

[Jon Skeet [C# MVP]]

(a lot snipped)

How can an SQLException be given back by a Server that is not connected with
your client.?

http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlexception.aspx

Why not give it a try? That's what I've just done. Here's the exception
I received:

System.Data.SqlClient.SqlException: A network-related or instance-
specific error occurred while establishing a connection to SQL Server.
The server was not found or was not accessible. Verify that the
instance name is correct and that SQL Server is configured to allow
remote connections. (provider: SQL Network Interfaces, error: 26 -
Error Locating Server/Instance Specified)

Satisfied now?

What exception do *you* think occurs (at the client side) when a SQL
database can't be reached?

 

[Cor Ligthert[MVP]]

From the top of the page from which I have sent you the link.

The exception that is thrown when SQL Server returns a warning or error. This class cannot be inherited.
So please tell Microsoft that they are wrong not me

Cor

 

[Cor Ligthert[MVP]]

Why did you try it, you was so sure of yourself.

But did you try the normal exception to see of this would not give almost
the same result in this not normal case.

My expirience is like that.

Cor

 

[Jon Skeet [C# MVP]]

Why did you try it, you was so sure of yourself.

So that I would be able to show the exact wording, as you seemed to
reject my assertion so completely.

But did you try the normal exception to see of this would not give almost
the same result in this not normal case.

My expirience is like that.

What do you mean by "try the normal exception"? Do you mean catching
just "Exception"? Yes, of course that will catch it. But let's look at
the first post I responded to in this thread:

<quote author="Cor">
I don't know if it was just speaking words, but an SQL exception should
only be in design time, because it catches the errors you have made in
your scripts.
</quote>

That's what I was disputing. There are various reasons why you may see
a SQL exception at execution time. SQL exceptions are to indicate
database errors, and those can occur for reasons other than "errors you
have made in your scripts" - and even errors in SQL may only be visible
in certain situations.

 

[Jeroen Mostert]

From the top of the page from which I have sent you the link.

The exception that is thrown when SQL Server returns a warning or error.
This class cannot be inherited.

So please tell Microsoft that they are wrong not me

The MSDN documentation is incomplete *and* you are wrong. I don't see how
these two exclude each other...

From the rest of the thread it's obvious that you're out to prove you're
right and the rest is wrong, even if you have to keep shifting the topic.
This discussion serves no further point, if indeed it ever served any.

 

[Arne Vajhøj]

Did you see my msdn link about the SQLException and how will you get
from the server any information as you have not even a cable to it?

????

The exception object is created by the SQLServer ADO.NET provider
running client side, so no problem.

Arne

 

[Arne Vajhøj]

From the top of the page from which I have sent you the link.

The exception that is thrown when SQL Server returns a warning or error.
This class cannot be inherited.

So please tell Microsoft that they are wrong not me

You are completely wrong about this.

The documentation is not particular good. Whoever wrote
that must have assumed that it was obvious that no
connectivity would also result in that exception.
What else could happen ?

Arne

 

[Arne Vajhøj]

Why did you try it, you was so sure of yourself.

To please you and post a specific example.

It is more surprising that you did not try it considering
how many have told you that you was wrong.

Arne

 

[Cor Ligthert[MVP]]

And I look on your reply on that.

And of course nothing *ever* goes wrong with valid SQL... The database
never goes down, there are never concurrency violations, locking
problems, failing to find expected data etc.

You are now still only talking about the one exception, where you show the
most basic exception related to ADONET which is very often showed by
beginners in the ADONET newsgroup.

Cor

 

[Cor Ligthert[MVP]]

Beg your pardon,

I did not start this, I asked the OP if he was really talking about the
SQLException then some persons thought they knew everything better and
should attack me on that.

It would be very bad as the OP got the idea that the SQLException was
catching concurrency errors and more of those thinks like that.

Which was told by Jon who got not any reaction from the two others which
showed in fact the knowledge about it from all the three.

Cor

 

[Cor Ligthert[MVP]]

ROFL

You are completely wrong about this.

The documentation is not particular good. Whoever wrote
that must have assumed that it was obvious that no
connectivity would also result in that exception.
What else could happen ?

Arne

 

[Cor Ligthert[MVP]]

Read something about inheritance.

The SQLException is deriving from exception classes which all derive from
Exception.

Cor

 

[Jon Skeet [C# MVP]]

And I look on your reply on that.


You are now still only talking about the one exception, where you show the
most basic exception related to ADONET which is very often showed by
beginners in the ADONET newsgroup.

It's still an exception that contradicts your original point. Do you
really want me to go through the other examples I talked about and
reproduce all of them? Do you really believe they *won't* result in
SQL exceptions? If not, what do you think *will* happen?

Jon

 

[Jon Skeet [C# MVP]]

Beg your pardon,

I did not start this, I asked the OP if he was really talking about the
SQLException then some persons thought they knew everything better and
should attack me on that.

You made an inaccurate claim, which I corrected. In what way was that
"attacking" you? Note that I wasn't the one to claim that you were a
"jerk" of a developer. I wasn't the one to suggest buying a book on
ADO.NET to distinguish between client and server.

*You* were the one to make unnecessary personal attacks.

It would be very bad as the OP got the idea that the SQLException was
catching concurrency errors and more of those thinks like that.

Concurrency errors which are caught on the *srver* will indeed be
propagated by a SQL exception. Concurrency management performed on the
client is a different matter. Likewise if the server detects a
deadlock and aborts one transaction, that will invole a SQL exception.
Likewise any errors deliberately raised within stored procedures due
to business logic violations etc. (Note that in many situations the
person writing the stored proc isn't the same as the person writing
the code to call it.)

What *I* think would be very bad would be for the OP to believe that
SQL exceptions only catch "the errors you have made in your scripts".

Which was told by Jon who got not any reaction from the two others which
showed in fact the knowledge about it from all the three.

Your basic claim was that you shouldn't see any SQL exceptions except
at design time. Why can't you just admit you were wrong to say that?
There's no shame in being wrong; I'll readily admit when I've made a
mistake. You made a mistake here. Admit it and move on.

Jon

 

[HillBilly]

For what its worth here is how I recently decided to manage at least one
circumstance...

#region Method: IsDatabaseOffline()...
public void IsDatabaseOffline()
{
// Is the database online or offline?
//
// Get a connection string from web.config and attempt
// to open a database connection. If the database is
// offline a SqlException will occur and the catch block
// will redirct to an error message page. If the database
// is online the connection will be opened, closed and
// disposed for garbage collection. Logging in or accessing
// the database for other purposes can then proceed as expected.

bool SqlExceptionCaught = false;

SqlConnection connection =
new SqlConnection(GetConnectionString("ConnectionStringName"));

if (!String.IsNullOrEmpty(connection.ToString()))
{
try
{
connection.Open();
connection.Close();
connection.Dispose();
}
catch (SqlException ex)
{
SqlExceptionCaught = true;
...
}

if(SqlExceptionCaught)
{
// do something...
}
}
}
#endregion