[RESOLVED] Error Trapping

[RobDog888]

It used to be asey in VB6 to trap for a particular error number but not now.
I want to trap for the failure of a SQL connection. Since there can be many reasons for failure I want to trap by the error number.
I found it during runtime in what looked like ex.innermessage.number but I cant get to it. How do I do it properly?

TIA.

'<CONNECT TO SQL DB>
Try
    goSQLConn = New SqlConnection
    goSQLConn.ConnectionString = "Data Source=MyServer;Initial Catalog=MyDB;Integrated Security=SSPI;"
    goSQLConn.Open()
Catch ex As Exception
    If ex.number = 4060 Then '<-- no dice :(
 
    End If
End Try
'</CONNECT TO SQL DB>

[kfcSmitty]

don't have .NET on this pc..but did you try

err.number?

[RobDog888]

Yup, and it didnt like it. It said for me to stop writting code using VB6 syntax.

[techgnome]

kfcSmitty - the err object no longer exists in .NET.....

RD - dang it.... I know I just saw a post on this exact thing recently..... search for posts with my username and "exception" and "error" and "handling"...... You might have to dig a little, but there's a thread out there that has sample code on how to do that.

Tg

[kfcSmitty]

http://msdn.microsoft.com/library/de...tml/vb01f1.asp

this help at all?

[techgnome]

Try this thread: http://vbforums.com/showpost.php?p=1986008&postcount=5

Tg

[wossname]

try this...

Catch ex as SqlException

Or look up SqlConnection.Open in MSDN. It has a list of exceptions thrown by this class.

Exceptions come in many shapes and forms, they are probably the most commonly derived classes in .Net.

All exceptions ultimately derive from Class Exception, but lets say you invented a class that does lots of complex things and could go wrong in many ways, you'd first create a class called RobDogException which inherits from Exception.

Then when you want to make this new class the base class of all your custom exceptions that are unique to your class. Some people call this an Exception family. I usually make an exception family for all my large classes, makes your code more robust and makes life easier for coders using your class to track down problems.

[RobDog888]

w00t w00t, I got it from Tgs link where Kleinma shows the SQLException object.

'<CONNECT TO SQL DB>
Try
    goSQLConn = New SqlConnection
    goSQLConn.ConnectionString = "Data Source=MyServer;Initial Catalog=MyDB;Integrated Security=SSPI;"
    goSQLConn.Open()
Catch exSQL As SqlException
    If exSQL.Errors.Item(0).Number = 4060 Then
        MessageBox.Show(exSQL.Errors.Item(0).Message, exSQL.Errors.Item(0).Number.ToString _
        & ": " & exSQL.Errors.Item(0).Source, MessageBoxButtons.OK, MessageBoxIcon.Error)
    End If
Catch ex As Exception
    MessageBox.Show(ex.Message.ToString, ex.Source, MessageBoxButtons.OK, MessageBoxIcon.Error)
End Try
'<CONNECT TO SQL DB>

[RobDog888]

Didnt refresh before I posted. Didnt see your post wossy. It was right on though.

I digged into the exsql and found the number property.

Thanks Guys,
Scooby snacks for everyone!

I must be having a good day

[jmcilhinney]

Note that it is recommended that new exception classes be derived from ApplicationException rather than Exception.

[RobDog888]

Why and can you show me an example.

[jmcilhinney]

I read the help topic "Introduction to Exception Handling in Visual Basic .NET" just the other day, and slightly misread it, it would seem. It says that there two exception base classes: System.Exception and Application.Exception. It says that when creating new exception classes we should inherit them from Application.Exception. Whoops, missed the dot. There's an example in that help topic.

Hey, now I'm reading the help topic "ApplicationException Class" and it says we should inherit from System.ApplicationException. The aforementioned example does just that, so I was right after all. Somebody stuffed up the help and it wasn't me.

[RobDog888]

I didnt realize that you could inherit from the exception object. What would be the correct way to error handle then since
there are so many as compared to vb6?

[jmcilhinney]

In most circumstances I find that I don't care what type of exception has been thrown, only that one has been. Therefore, I usually just use a single Catch block for an Exception that handles all cases. Every Framework method that can throw an exception has details of the types it can throw in the documentation, so you always know what exception types you need to consider, if you do indeed want to handle them differently. Any developer who creates and distributes their own components should include similar documentation. That way the types of exceptions you need to consider for any operation are known beforehand and can be handled accordingly.

[RobDog888]

So I take it that its not usual to inherit from System.ApplicationException to do you error handling?

[jmcilhinney]

I only really do small time stuff, but I've never had the need to create my own custom exception classes. I've always found those provided by the Framework to be sufficient. If you do have a need for a custom exception, according to the documentation you should inherit from ApplicationException rather than Exception. If I remember what I read properly, ApplicationException inherits from Exception but adds no new functionality. Inheriting from it simply indicates that your exception was thrown by the application rather than the system.

[wossname]

All you need to do in order to catch exceptions is to know which ones too look out for. Lets say you have 5 different ones that could all be thrown by a class. Look to see which is the base exception that all 5 are derived from and then just CATCH that.

Easy.

[RobDog888]

An example if you would, please. Havent had any coffee yet.