Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

C# exception handling question 1

Status
Not open for further replies.

SulikSlayer

Programmer
Nov 16, 2002
17
KG
I heard that using exceptions in C++ sometimes causes unpredictable results, even suspending the syspem. Rarely, of course, but it can be destructing in case of business project.
The alternative is writing a module for error handling not using exceptions at all. This is more difficult way, so here goes my question:
Were there any tweaks done in .NET (C#) with exceptions, perhaps making them less dangerous to use, and more reliable?
And, please, could anyone give a short overview of exception difficulties in use and possible errors concerning them.
Thanks in advance.
 
Exceptions are much better integrated into the .NET environment. No more having to choose between Win32 exceptions and C++ exceptions (neither of which were that fun to work with).

I've pretty much decided that exceptions are there to catch programmer errors, not user errors. If a user supplies bad input, then my code should have caught it. If a network resource is unavailable, or if the database connect string is wrong, then an exception should catch it.

One thing that is a little unusual in .NET exceptions is that the variable scope spans the try, catch, and finally blocks. So you can't do something like this:
Code:
try {
   SqlConnection MyConnect = new SqlConnection(connectString);
} catch (Exception e) {
   MessageBox.Show(e.Message);
} 
MyConnect.Close();
because the compiler will complain about no instance of MyConnect being found for the Close method. Do something like this:
Code:
SqlConnection MyConnect = null;
try {
   MyConnect = new SqlConnection(connectString);
} catch (Exception e) {
   MessageBox.Show(e.Message);
} 
MyConnect.Close();
Or even better, move the Close call into a Finally section.

Chip H.
 
So, I can assume the Finally section has the same area of vision as the try-catch block?

I mean if I have placed the Close call in the first example into the Finally block - there will be an instance found, right?


And I'm still curious about exceptions reliability. I mean, they do work rather slow, but do they work properly or not?
 
I mean if I have placed the Close call in the first example into the Finally block - there will be an instance found, right?

Correct.

And I'm still curious about exceptions reliability. I mean, they do work rather slow, but do they work properly or not?

AFAIK, the exception handling in .NET is very reliable, as it's used by the framework itself. So any "problems" would have appeared very quickly during its development. It works for me. :)

Using try..catch..finally blocks has very little performance impact, but throwing an exception (whether by you using the throw function, or a system-generated exception) is expensive. So handle exceptions as soon as you can (logging them, whatever).

Chip H.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top