Handling exceptions

[Sweetiecakes]

Hello

I'm a bit confused on how one should handle exceptions. I'm currently
building an ADO.NET Windows Forms application. I've built a class for
manipulating data within the database in question. This class is used
from forms. Let's assume that there is an SQL error: this will throw an
exception. Where should I handle it? How should I handle it? What to
show when giving an error message?

Is there any "centralized" way of handling exceptions: for example,
having a centralized exception handler catch everything, and show an
error message relative to the caught exception?

Thanks

[Bela Istok]

Ok this is a multi answer question because there is no a right way to handle
all the exceptions, one that works for me is:
First if the Exception is an expected exception handle that near the code
that gives the Exception.
Second if you can recover from the exception do it near when it's throwing.
If you don't know or expect the exception and because you are using windows
form you can set a Global exception handler in the application object like
this:
Application.SetUnhandledExceptionMode(UnhandledExc eptionMode.Automatic);
Application.ThreadException += new
System.Threading.ThreadExceptionEventHandler(Appli cation_ThreadException);
static void Application_ThreadException(object sender,
System.Threading.ThreadExceptionEventArgs e)
{
//Handle here an Unhandled Exception
}

And there you will handle an unexpected exception, but there is a catch, you
need to know if the application can continue after the exception or not.

Regards,

Bela Istok
"Sweetiecakes" <[e-mail] in message
news:48***********************@news.fv.fi...

Hello

I'm a bit confused on how one should handle exceptions. I'm currently
building an ADO.NET Windows Forms application. I've built a class for
manipulating data within the database in question. This class is used from
forms. Let's assume that there is an SQL error: this will throw an
exception. Where should I handle it? How should I handle it? What to show
when giving an error message?

Is there any "centralized" way of handling exceptions: for example, having
a centralized exception handler catch everything, and show an error
message relative to the caught exception?

Thanks

[Cor Ligthert[MVP]]

SweetieCakes,

A very retro question you ask, I think from about the 70's.

But you can of course make a method that handles those in a kind of general
way and pass the exception.

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

"Sweetiecakes" <[e-mail] in bericht
news:48***********************@news.fv.fi...

Hello

I'm a bit confused on how one should handle exceptions. I'm currently
building an ADO.NET Windows Forms application. I've built a class for
manipulating data within the database in question. This class is used from
forms. Let's assume that there is an SQL error: this will throw an
exception. Where should I handle it? How should I handle it? What to show
when giving an error message?

Is there any "centralized" way of handling exceptions: for example, having
a centralized exception handler catch everything, and show an error
message relative to the caught exception?

Thanks

[Jeroen Mostert]

Cor Ligthert[MVP] wrote:

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.

I'm in your server room *right now*, unplugging your network. Let's see how
your users like cryptic error messages. :-)

--
J.

[Jon Skeet [C# MVP]]

Cor Ligthert[MVP] <no************@planet.nlwrote:

A very retro question you ask, I think from about the 70's.

But you can of course make a method that handles those in a kind of general
way and pass the exception.

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.

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.

There are plenty of reasons why you may see SQL exceptions at execution
time.

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

[Bela Istok]

Let's not shoot him about this message.

Regards,

Bela Istok
"Cor Ligthert[MVP]" <no************@planet.nlwrote in message
news:24**********************************@microsof t.com...

SweetieCakes,

A very retro question you ask, I think from about the 70's.

But you can of course make a method that handles those in a kind of
general way and pass the exception.

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

"Sweetiecakes" <[e-mail] in bericht
news:48***********************@news.fv.fi...

>Hello

I'm a bit confused on how one should handle exceptions. I'm currently
building an ADO.NET Windows Forms application. I've built a class for
manipulating data within the database in question. This class is used
from forms. Let's assume that there is an SQL error: this will throw an
exception. Where should I handle it? How should I handle it? What to show
when giving an error message?

Is there any "centralized" way of handling exceptions: for example,
having a centralized exception handler catch everything, and show an
error message relative to the caught exception?

Thanks

[sloan]

Check this entry out:
http://blogs.msdn.com/kcwalina/archi...16/396787.aspx


"Sweetiecakes" <[e-mail] in message
news:48***********************@news.fv.fi...

Hello

I'm a bit confused on how one should handle exceptions. I'm currently
building an ADO.NET Windows Forms application. I've built a class for
manipulating data within the database in question. This class is used from
forms. Let's assume that there is an SQL error: this will throw an
exception. Where should I handle it? How should I handle it? What to show
when giving an error message?

Is there any "centralized" way of handling exceptions: for example, having
a centralized exception handler catch everything, and show an error
message relative to the caught exception?

Thanks

[Bela Istok]

Nice post sloan, but this is the opposite site of the question. The Cwalina
post talks about throwing exceptions not handling the exceptions. But it's
good to know that too.

Regards,

Bela Istok

"sloan" <sl***@ipass.netwrote in message
news:OR****************@TK2MSFTNGP04.phx.gbl...

>>
Check this entry out:
http://blogs.msdn.com/kcwalina/archi...16/396787.aspx


"Sweetiecakes" <[e-mail] in message
news:48***********************@news.fv.fi...

>>Hello

I'm a bit confused on how one should handle exceptions. I'm currently
building an ADO.NET Windows Forms application. I've built a class for
manipulating data within the database in question. This class is used
from forms. Let's assume that there is an SQL error: this will throw an
exception. Where should I handle it? How should I handle it? What to
show when giving an error message?

Is there any "centralized" way of handling exceptions: for example,
having a centralized exception handler catch everything, and show an
error message relative to the caught exception?

Thanks

[sloan]

Most times, you will write

try
{}
finally
{}

blocks. notice no "catch". You don't catch them.

Then, in your presentation layer, you can catch them.

try
{

}
catch(Exception ex)
{
MessageBox.Show(ex.Message);
//Response.Write(ex.Message); //asp.net

}
There's one more tactic. When you want to catch a dotNet, un-user friendly
exception, and make it into something nicer.

This might be in the BAL layer.

try
{
//try something against the db ........
}
catch ( SqlException sqlex )
{
throw new MyCustomDatabaseIsDownException( "Sorry, the db is currently not
working" , sqlex );
}
catch (Exception ex)
{
throw new MyCustomNonHandledException ("Something unexpected happened."
, ex);
}
Its usually a good practice to take the "real" exception and make it the
".InnerException"...when you create your own exception classes. Which you
can handle with the overloaded constructor.

Most times I don't wrap 'em up for the user nice-like. But that's me.
Depending on the audience and application, you might want to wrap 'em up
nice-like.
............

"Bela Istok" <be****@hotmail.comwrote in message
news:%2******************@TK2MSFTNGP06.phx.gbl...

Nice post sloan, but this is the opposite site of the question. The
Cwalina
post talks about throwing exceptions not handling the exceptions. But it's
good to know that too.

Regards,

Bela Istok

>"sloan" <sl***@ipass.netwrote in message
news:OR****************@TK2MSFTNGP04.phx.gbl...

>>>
Check this entry out:
http://blogs.msdn.com/kcwalina/archi...16/396787.aspx


"Sweetiecakes" <[e-mail] in message
news:48***********************@news.fv.fi...
Hello

I'm a bit confused on how one should handle exceptions. I'm currently
building an ADO.NET Windows Forms application. I've built a class for
manipulating data within the database in question. This class is used
from forms. Let's assume that there is an SQL error: this will throw an
exception. Where should I handle it? How should I handle it? What to
show when giving an error message?

Is there any "centralized" way of handling exceptions: for example,
having a centralized exception handler catch everything, and show an
error message relative to the caught exception?

Thanks

[Cor Ligthert[MVP]]

Jon,

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.

As far as I know them will the SQLException ignore all of those problems you
are showing

The SQLexception is needed to check if a stored procedure or an parameter in
that does not exist.
But you are in my opinion a jerk of a developer as you are testing that at
run time.

Cor

[Jeroen Mostert]

Cor Ligthert[MVP] wrote:

Jon,

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

As far as I know them will the SQLException ignore all of those problems
you are showing

Why are you second-guessing this with "as far as I know"? Wouldn't you at
least like to try it first before simply reasserting what someone else has
drawn into question?

An SqlException will be raised for *any* critical error signaled by the
database, including lock timeouts, I/O errors, wrong logins and plain and
simple unreachability of the database, none of which are predictable by the
application developer. I know this because I've seen it. Can you say you've
seen the opposite?

There *are* some errors that are not translated to an SqlException, and it's
also true that some SqlExceptions are not raised until you've read all the
result sets, but it's definitely not true that any SqlException can be
predicted at design time.

The SQLexception is needed to check if a stored procedure or an
parameter in that does not exist.
But you are in my opinion a jerk of a developer as you are testing that
at run time.

Since the facts you base your opinion on are wrong, that doesn't mean much.

--
J.

[Jon Skeet [C# MVP]]

Cor Ligthert[MVP] <no************@planet.nlwrote:

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.

As far as I know them will the SQLException ignore all of those problems you
are showing

Nope.

The SQLexception is needed to check if a stored procedure or an parameter in
that does not exist.

Nope.

From the docs:

<quote>
This class is created whenever the .NET Framework Data Provider for SQL
Server encounters an error generated from the server.
</quote>

There are plenty of errors which a database can encounter at execution
time beyond just whether or not your SQL is valid and calling valid
stored procs with the right number of parameters.

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

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Cor Ligthert[MVP] wrote:

Jon,

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

As far as I know them will the SQLException ignore all of those problems
you are showing

The SQLexception is needed to check if a stored procedure or an
parameter in that does not exist.
But you are in my opinion a jerk of a developer as you are testing that
at run time.

No.

ADO.NET does not return status values.

Either it is a success all the way through or you get an
exception.

The only bad thing about the exception is that you get the
same exception type for too many different problems. I guess
that will be fixed in .NET 4.0 or 5.0 !

Arne

[Cor Ligthert[MVP]]

Jeroen,

You give your own answer, the SQLException is about errors raised at Server
side. Which I as I have them, seriously evaluate the program before I give
them to the users, because those are in my opinion all design time errors
(including the environment), I never have lock errors as I use never any
more the old fashion way of setting lock bits, which is not based on modern
processing with 1000 users online anymore.

The rest of the errors which you give are by the way as well catched at
client side with the normal exception, which I forever use and before that
and try before processing if the database is online with a normal exception
to check if the connection is correct.

However, feel free to do it your way.

Cor
"Jeroen Mostert" <jm******@xs4all.nlschreef in bericht
news:48*********************@news.xs4all.nl...

Cor Ligthert[MVP] wrote:

>Jon,

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

As far as I know them will the SQLException ignore all of those problems
you are showing

Why are you second-guessing this with "as far as I know"? Wouldn't you at
least like to try it first before simply reasserting what someone else has
drawn into question?

An SqlException will be raised for *any* critical error signaled by the
database, including lock timeouts, I/O errors, wrong logins and plain and
simple unreachability of the database, none of which are predictable by
the application developer. I know this because I've seen it. Can you say
you've seen the opposite?

There *are* some errors that are not translated to an SqlException, and
it's also true that some SqlExceptions are not raised until you've read
all the result sets, but it's definitely not true that any SqlException
can be predicted at design time.

>The SQLexception is needed to check if a stored procedure or an parameter
in that does not exist.
But you are in my opinion a jerk of a developer as you are testing that
at run time.

Since the facts you base your opinion on are wrong, that doesn't mean
much.

--
J.

[Cor Ligthert[MVP]]

Jon,

Buy a book about AdoNet and try to understand what is Server side and what
is Client side in that.

Cor

"Jon Skeet [C# MVP]" <sk***@pobox.comschreef in bericht
news:MP*********************@msnews.microsoft.com. ..

Cor Ligthert[MVP] <no************@planet.nlwrote:

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.

As far as I know them will the SQLException ignore all of those problems
you
are showing

Nope.

>The SQLexception is needed to check if a stored procedure or an parameter
in
that does not exist.

Nope.

From the docs:

<quote>
This class is created whenever the .NET Framework Data Provider for SQL
Server encounters an error generated from the server.
</quote>

There are plenty of errors which a database can encounter at execution
time beyond just whether or not your SQL is valid and calling valid
stored procs with the right number of parameters.

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

[Cor Ligthert[MVP]]

Arne,

Can you point me where your answer is about. I don't have the idea to have
written anything about a Status.

But what you wrote is in my opinion true, although you can catch with the
SQLException some information why the SQL transaction on the Server Side
went wrong. However, in my opinion a designer should fix all those errors
which are catched here fix before he gives his program in production. (Or
catch them at client side as it is hardware dependend, I have never seen a
server, which was down, give any information)

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

Cor

"Arne Vajhøj" <ar**@vajhoej.dkschreef in bericht
news:48***********************@news.sunsite.dk...

Cor Ligthert[MVP] wrote:

>Jon,

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

As far as I know them will the SQLException ignore all of those problems
you are showing

The SQLexception is needed to check if a stored procedure or an parameter
in that does not exist.
But you are in my opinion a jerk of a developer as you are testing that
at run time.

No.

ADO.NET does not return status values.

Either it is a success all the way through or you get an
exception.

The only bad thing about the exception is that you get the
same exception type for too many different problems. I guess
that will be fixed in .NET 4.0 or 5.0 !

Arne

[Jon Skeet [C# MVP]]

On Aug 11, 6:13*am, "Cor Ligthert[MVP]" <[e-mail]>
wrote:

Buy a book about AdoNet and try to understand what is Server side and what
is Client side in that.

I don't need to buy a book to know that things can go wrong in a
database beyond SQL validation errors, and when those things happen,
you get a SQL exception.

I suggest you try writing an application which constantly accessed a
database, and shut the database down while it's running. See what
happens.

Jon

[Jeroen Mostert]

Cor Ligthert[MVP] wrote:

You give your own answer, the SQLException is about errors raised at
Server side. Which I as I have them, seriously evaluate the program
before I give them to the users, because those are in my opinion all
design time errors (including the environment),

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

I never have lock errors as I use never any more the old fashion way of
setting lock bits, which is not based on modern processing with 1000
users online anymore.

Locking is a cornerstone of most implementations of ACID, and I'm not
talking about explicit client-side locking. But let's move on, this is a
side issue.

The rest of the errors which you give are by the way as well catched at
client side with the normal exception, which I forever use and before
that and try before processing if the database is online with a normal
exception to check if the connection is correct.

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

However, feel free to do it your way.

We have in no way, shape or form entered the realm of personal preference in
this discussion. The issues mentioned here are going to be part of every
error-handling strategy, and I haven't said anything about how such a
strategy should look. Asynchronous exceptions while accessing a database
server are a simple fact of life. It is the very nature of these exceptions
that no amount of design-time cleverness will eliminate them.

I strongly get the feeling that we're talking about completely different
thigns without realizing it.

--
J.

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Cor Ligthert[MVP] wrote:

"Arne Vajhøj" <ar**@vajhoej.dkschreef in bericht
news:48***********************@news.sunsite.dk...

>Cor Ligthert[MVP] wrote:

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

As far as I know them will the SQLException ignore all of those
problems you are showing

The SQLexception is needed to check if a stored procedure or an
parameter in that does not exist.
But you are in my opinion a jerk of a developer as you are testing
that at run time.

No.

ADO.NET does not return status values.

Either it is a success all the way through or you get an
exception.

The only bad thing about the exception is that you get the
same exception type for too many different problems. I guess
that will be fixed in .NET 4.0 or 5.0 !

Can you point me where your answer is about. I don't have the idea to
have written anything about a Status.

There are only two alternatives for returning errors: exceptions and
status codes. So since .NET does not have status codes, then the
choices are somewhat limited-

But what you wrote is in my opinion true, although you can catch with
the SQLException some information why the SQL transaction on the Server
Side went wrong.

You can, but that is very bad OOP.

However, in my opinion a designer should fix all those
errors which are catched here fix before he gives his program in
production.

None of the problems Jon list is permanent problems. They can
happen in production even if they do not happen in test.

And even if the database server did go down under test, then I am not
quite sure what the designer should fix ? Not use a database ??

(Or catch them at client side as it is hardware dependend, I
have never seen a server, which was down, give any information)

I am not quite sure what you mean by client and server here, but
since it is about database access let us assume database client
and server.

If the database server si down, then the database client will
get an exception and need to handle it. Like Jon explained.

Arne

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Cor Ligthert[MVP] wrote:

"Jeroen Mostert" <jm******@xs4all.nlschreef in bericht
news:48*********************@news.xs4all.nl...

>Cor Ligthert[MVP] wrote:

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

As far as I know them will the SQLException ignore all of those
problems you are showing

Why are you second-guessing this with "as far as I know"? Wouldn't you
at least like to try it first before simply reasserting what someone
else has drawn into question?

An SqlException will be raised for *any* critical error signaled by
the database, including lock timeouts, I/O errors, wrong logins and
plain and simple unreachability of the database, none of which are
predictable by the application developer. I know this because I've
seen it. Can you say you've seen the opposite?

There *are* some errors that are not translated to an SqlException,
and it's also true that some SqlExceptions are not raised until you've
read all the result sets, but it's definitely not true that any
SqlException can be predicted at design time.

>>The SQLexception is needed to check if a stored procedure or an
parameter in that does not exist.
But you are in my opinion a jerk of a developer as you are testing
that at run time.

Since the facts you base your opinion on are wrong, that doesn't mean
much.

You give your own answer, the SQLException is about errors raised at
Server side. Which I as I have them, seriously evaluate the program
before I give them to the users, because those are in my opinion all
design time errors (including the environment), I never have lock errors
as I use never any more the old fashion way of setting lock bits, which
is not based on modern processing with 1000 users online anymore.

It is completely impossible to find all problems that could happen
with a database server.

There is a reason that clustering is used if uptime is needed.

The rest of the errors which you give are by the way as well catched at
client side with the normal exception, which I forever use and before
that and try before processing if the database is online with a normal
exception to check if the connection is correct.

Oh - if the database is working when you start then it will continue
to work ?

Do you have that in writing from MS ??

Arne

[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

"Arne Vajhøj" <ar**@vajhoej.dkschreef in bericht
news:48***********************@news.sunsite.dk...

Cor Ligthert[MVP] wrote:

>"Arne Vajhøj" <ar**@vajhoej.dkschreef in bericht
news:48***********************@news.sunsite.dk. ..

>>Cor Ligthert[MVP] wrote:
Jon,
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.
>
As far as I know them will the SQLException ignore all of those
problems you are showing

The SQLexception is needed to check if a stored procedure or an
parameter in that does not exist.
But you are in my opinion a jerk of a developer as you are testing that
at run time.

No.

ADO.NET does not return status values.

Either it is a success all the way through or you get an
exception.

The only bad thing about the exception is that you get the
same exception type for too many different problems. I guess
that will be fixed in .NET 4.0 or 5.0 !

Can you point me where your answer is about. I don't have the idea to
have written anything about a Status.

There are only two alternatives for returning errors: exceptions and
status codes. So since .NET does not have status codes, then the
choices are somewhat limited-

>But what you wrote is in my opinion true, although you can catch with the
SQLException some information why the SQL transaction on the Server Side
went wrong.

You can, but that is very bad OOP.

> However, in my opinion a designer should fix all those
errors which are catched here fix before he gives his program in
production.

None of the problems Jon list is permanent problems. They can
happen in production even if they do not happen in test.

And even if the database server did go down under test, then I am not
quite sure what the designer should fix ? Not use a database ??

(Or catch them at client side as it is hardware dependend, I
have never seen a server, which was down, give any information)

I am not quite sure what you mean by client and server here, but
since it is about database access let us assume database client
and server.

If the database server si down, then the database client will
get an exception and need to handle it. Like Jon explained.

Arne

[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/libr...exception.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/libr...exception.aspx

Cor

[Jeroen Mostert]

Cor Ligthert[MVP] wrote:

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

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.

--
J.

[Jon Skeet [C# MVP]]

Cor Ligthert[MVP] <no************@planet.nlwrote:

(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/libr...exception.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?

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

[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

"Jeroen Mostert" <jm******@xs4all.nlschreef in bericht news:48*********************@news.xs4all.nl...

Cor Ligthert[MVP] wrote:

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

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.

--
J.

[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]" <sk***@pobox.comschreef in bericht
news:MP*********************@msnews.microsoft.com. ..

Cor Ligthert[MVP] <no************@planet.nlwrote:

>(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/libr...exception.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?

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

[Jon Skeet [C# MVP]]

Cor Ligthert[MVP] <no************@planet.nlwrote:

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.

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

[Jeroen Mostert]

Cor Ligthert[MVP] wrote:

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.

--
J.

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Cor Ligthert[MVP] wrote:

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

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Cor Ligthert[MVP] wrote:

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

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Cor Ligthert[MVP] wrote:

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

"Jon Skeet [C# MVP]" <sk***@pobox.comschreef in bericht
news:MP*********************@msnews.microsoft.com. ..

Cor Ligthert[MVP] <no************@planet.nlwrote:

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

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

[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

"Jeroen Mostert" <jm******@xs4all.nlschreef in bericht
news:48*********************@news.xs4all.nl...

Cor Ligthert[MVP] wrote:

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

--
J.

[Cor Ligthert[MVP]]

ROFL

"Arne Vajhøj" <ar**@vajhoej.dkschreef in bericht
news:48***********************@news.sunsite.dk...

Cor Ligthert[MVP] wrote:

>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

[Cor Ligthert[MVP]]

Read something about inheritance.

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

Cor

"Arne Vajhøj" <ar**@vajhoej.dkschreef in bericht
news:48***********************@news.sunsite.dk...

Cor Ligthert[MVP] wrote:

>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

[Jon Skeet [C# MVP]]

On Aug 13, 5:51*am, "Cor Ligthert[MVP]" <[e-mail]>
wrote:

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.

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

On Aug 13, 6:00*am, "Cor Ligthert[MVP]" <[e-mail]>
wrote:

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("ConnectionStrin gName"));

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

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

"Sweetiecakes" <[e-mail] in message
news:48***********************@news.fv.fi...

Hello

I'm a bit confused on how one should handle exceptions. I'm currently
building an ADO.NET Windows Forms application. I've built a class for
manipulating data within the database in question. This class is used from
forms. Let's assume that there is an SQL error: this will throw an
exception. Where should I handle it? How should I handle it? What to show
when giving an error message?

Is there any "centralized" way of handling exceptions: for example, having
a centralized exception handler catch everything, and show an error
message relative to the caught exception?

Thanks