[RESOLVED] [2005] Error Handling Is Creating Errors I Didn't Have Before

I'm adding error handling to code that I know works and am encountering a rather odd error in doing so (at least it is odd to me.) Note the following code

Code:

---

'code above this that works fine
    Dim da As New System.Data.SqlClient.SqlDataAdapter(sSQL, myConnection)
    da.Fill(ds)
    Dim rowcount As Integer = ds.Tables.Item(0).Rows.Count
    'now, for the display, we need to use the datareader
    Dim command As New SqlCommand(sSQL, myConnection)
    Dim reader As SqlDataReader = command.ExecuteReader()
'code below this that also works fine.

---

Now, I throw in some error handling

Code:

---

'code above this that works fine
      Try
            Dim da As New System.Data.SqlClient.SqlDataAdapter(sSQL, myConnection)
            da.Fill(ds)
            Dim rowcount As Integer = ds.Tables.Item(0).Rows.Count
            'now, for the display, we need to use the datareader
            Dim command As New SqlCommand(sSQL, myConnection)
            Dim reader As SqlDataReader = command.ExecuteReader()
        Catch ex As Exception
            MessageBox.Show(ex.Message & " " & ex.Source)
        End Try
'code below this that also works fine

---

Now, with the error handing, I'm getting two errors I never had before:

1. Name 'rowcount' is not declared
2. Name 'reader' is not declared

:confused: Huh? I can't declare something after a Try? :confused:

I suspect you are using rowcount and reader outside of your try catch.... problem is they are defined inside the TRy.... which means that's the only place they are visible. If you need them outside of the Try, then Dim them outside the Try. It's a scope thing.

-tg

Where us tge error? I have had errors (same as yours) if I decalre in the Try and then use it outside the Try statement.

Way to slow for tg again.

With .NET you can now have code block scoped variables as a finer way to narrow down scopes.

Quote:

---

Originally Posted by techgnome

It's a scope thing.

---

I understand scope errors. :D

As long as I have this thread, I'll ask another question.

I bought "murach's VB.NET database programming with ADO.NET" - in the section that deals with error trapping, the book shows examples of multiple Catch statements that deal with specific errors rather than just one all encompassing Try/Catch to deal with any error that happens to occur.

Which approach do you guys use? Or, do you use a combination of both depending on what you are error trapping?

I will use a SQL error trap on SQL more often then not and also on CR in the viwer form to Display any CR error. They will also have a standard error catch to display if not the specific Error type (to display the SQL string if running)...

The logic is to only catch and error when you are going to do something with it. Using nested try catch blocks do take up a bit more resources too. But a multiple case try catch is good if you are going to be handling each different caase differently. Only code in what you are going to handle.

Should you want to handle ALL errors?

I would think so. If you use multiple catch statements you can display an error message tailored to the error being generated. Maybe on an SQL error write the SQL statement to a log file that can be sent to you for evaluation. An error that is not SQL maybe just display a message to the user. For a CR error maybe a log of that message and e-mail to a specific developer?

Quote:

---

Originally Posted by GaryMazzone

I would think so. If you use multiple catch statements you can display an error message tailored to the error being generated. Maybe on an SQL error write the SQL statement to a log file that can be sent to you for evaluation. An error that is not SQL maybe just display a message to the user. For a CR error maybe a log of that message and e-mail to a specific developer?

---

This is how it should be done. And remember that you may have a try catch block calling some function of yours and in that function have another try catch block. Which could end up being bubled back up to the calling function to handle any generic errors instead of a multiple cae block in the function and use only two catch scenerios etc. One for a specific issue and another to puke it back up to the calling procedure.

This is one of the examples from the book

Code:

---

Try
  bmbVendors.EndCurrentEdit()
Catch eConstraint As ConstraintException
  Messagebox.Show(eConstraint.Message, "Constraint Error")
Catch eNull As NoNullAllowedException
  Messagebox.Show(eNull.Message, "Null error")
Catch eData As DataException
  Messagebox.Show(eData.Message, "ADO.NET error")
Catch eSystem As Exception
  MessageBox.Show(eSystem.Message, "System error")
End Try

---

While in theory, this seems like a very good idea, it in practice, it would mean that you would have to pour through just about every line of a sub/function/click/whatever and try to conceive of every possible error.

That sounds a little time consuming.

No because you may have a table that accepts nulls so no error would be generated for that scenerio. Remember, only create catches for what your needs are. Each will be different in each procedure. Perhaps your users dont need to see or would even understand what a "Constraint Error' was :D Then you would just want to puke "Error, data being written to log." or such and be done with that.

I think all of the examples you showed

Catch eConstraint As ConstraintException
Messagebox.Show(eConstraint.Message, "Constraint Error")
Catch eNull As NoNullAllowedException
Messagebox.Show(eNull.Message, "Null error")
Catch eData As DataException
Messagebox.Show(eData.Message, "ADO.NET error")

Could all be considered an SQLException. So maybe like this:

Code:

---

Try

Catch ex as SQLException
    messagebox.Show ("A database error has occured an a log file has been generated and e-mailed to the responsible party.","Database Error")
Catch ex as Exception
  messagebox.Show ("An unexpected application error has occured.","Unspecified Error")
End Try

---

If I were looking to trap a constraint error, the message they saw wouldn't say constraint. You are right....they would have no clue what that meant.

Like the book, I was just using that as an example.

I'm asking for opinions. .NET provides us with the ability to have more than just one, generic, error trap per routine. I'm wondering how many folks out there use this type of multiple Catch statements on a frequent basis or do you all just go with one all encompassing trap?

The majority of the time I use a single generic catch exception. But if its a task with a database act then I will catch an sqlexception and perhaps a generic one too. Thats about all unless its an involved sp or something but you can always get the same info from the stack trace, error message and inner exception (if it has one).

Gary/Rob: I'm so glad you both just said what you did, because it provides a perfect transition to my next question. I added this to one of my routines

Code:

---

      Catch exSQL As SqlException
            MessageBox.Show(exSQL.Message & " " & exSQL.Source, "LoadUserNames")
        Catch ex As Exception
            MessageBox.Show(ex.Message & " " & ex.Source, "LoadUserNames")

---

Question: An SqlException is also an Exception, is it not? If I ran into an SQL error, would I see two message boxs?

No... only one... generally when using this you put the more specific errors first, followed by more general/broader ones. Since the SQLException inheirits from system.exception, but contains specific data to SQL, it's listed first. If a system error happens, it's not of type SQLException, so it falls down to the next one. Think of it as a a SELECT CASE, where you are matching on exception types.

-tg

That is the way I figured it had to work, but I wanted to make sure.

Is there a hierarchy of Exception errors? What inherits from what and would a System error be the top dog?

Well, I just learned a lesson in inheritance. I had the constraint exception before the SQLException, and was told that the Catch would never be reached because ConstraintException inherits from SqlException.

That makes sense, so I move the constraint exception below SqlException, and that fixed that.

However, my first catch is for systemexception, followed by Sql, followed by Constraint, following general, as follows;

Code:

---

    Catch exSys As SystemException
            MessageBox.Show(exSys.Message & " " & exSys.Source, "Add New User")
        Catch exSQL As SqlException
            MessageBox.Show(exSQL.Message & " " & exSQL.Source, "Add New User")
        Catch exCont As ConstraintException
            MessageBox.Show(exCont.Message & " " & exCont.Source, "Add New User")
        Catch ex As Exception
            MessageBox.Show(ex.Message & " " & ex.Source, "Add New User")
        End Try

---

However, I'm now told the SqlException would not be reached because it inherits from System.SystemException.

Well, SystemException is the first catch, so why isn't it inheriting?

I would place the exSys execetion after the SQL exections and before the ex exception

Ok, that worked, but I don't understand why that worked.

I had an error message saying the SqlException inherited from System.SystemException. Wouldn't that mean the SystemException should come before SqlException?

no because the SystemException is the more general exception type.... SQLException is more specific... and ConstraintException is even more specific than that.

Let's use the typical car analogy and suppose were trapping based on Car types...

Code:

---

Catch c as Car
Catch cf as Ford
Catch cn as Nissan
Catch cfe as FordExplorer

---

Assuming FordExplorer inherits from Ford which in turn inherits from Car.... when a FordExporer exception happens.... it'll get trapped by the generic Car. It's the first compatible match.

So, we put car at the bottom....

Code:

---

Catch cf as Ford
Catch cn as Nissan
Catch cfe as FordExplorer
Catch c as Car

---

Now, when the FordExplorer exception happens.... it'll get caught by Ford....
Still not quite what we want
Move FordExporer up...

Code:

---

Catch cfe as FordExplorer
Catch cf as Ford
Catch cn as Nissan
Catch c as Car

---

Now we have specific errors handled first... followed by more general ones, followed lastly by the most generic handler (the car).

Does that help?

-tg

Quote:

---

Originally Posted by techgnome

Now we have specific errors handled first... followed by more general ones, followed lastly by the most generic handler (the car).
Does that help?

---

Perfect sense. I was looking at it from a top/down perspective instead of a bottom/up.

Making the more specific error traps come first and the most generic error traps last makes total sense.

One last question on this. I had to laugh.

I was going throught the intellisense list of all of the Exceptions I could trap for. Pretty darn impressive if you ask me.

Then I hit

Code:

---

Catch ex As Microsoft.SqlServer
'or
Catch ex As Microsoft.VisualBasic

---

So, I Googled these two. The SQL Server one came back with things like being able to trap for synchronization errors or replication errors and I thought that was pretty cool.

But, I don't get the VisualBasic one. More than likely no one has ever used that, but I was wondering if anyone knew what the heck it would be for.

This is just a curiousity question. My original question has long since been answered. :D

Perhaps its for trapping legacy sickly looking VB 6 code in the MS.VB class. :lol:

Quote:

---

Originally Posted by RobDog888

Perhaps its for trapping legacy sickly looking VB 6 code in the MS.VB class. :lol:

---

Then it should be made mandatory like having Option Strict On - :thumb:

Thanks to all.

It's not VB6 stuff, but errors kicked by VB in general (if it was for VB6 type errors, it would be System.Compatibility.VisualBasic (or some thing like that). It's possible that there are some kind of errors that can be thrown that are specific to the language implementation, that may not be in another.

I'd also like to note that it's only necessary to trap for specific exceptions (or types of exceptions) if you want to do something different with each one. If they are all going to be treated the same way, it's only necessary to trap for ex As Exception. If you want to do action A based on, say for instance, connection to the database couldn't be made, action B, if the SP fails, action C if a constraint fails, then you would trap four items: one for unable to open connection (I don't remember what the specific error type is), one for SQLConstraintException, one for SqlException (for the generic SQL failures), and one for Exception.

Otherwise you could make yourself go crazy trying to figure out all of the possible combinations.

-tg

Quote:

---

Originally Posted by techgnome

Otherwise you could make yourself go crazy trying to figure out all of the possible combinations.

---

That was a conclusion I made even before I tried. :)

However, given that all of my programming is database related, I think I will be employing both the constraint and sql exceptions as well as the general exception.

Good choice.

-tg