How do I explore the error information in a .NET TCP Connect async callback?

So, I wrote a TCP client in VB.NET using the asynchronous functions.  When I try to connect to an inactive server I get an exception in the "Connection" callback saying the connection was refused by the remote PC, which is fine.

However, I'm trying to *handle* this circumstance and having trouble.  When I but a breakpoint/watch on the IAsyncResult returned by the callback, I can see an error code (see Figure 1).  But that "ErrorCode" does not seem to be a member of the returned IAsyncResult object, perhaps a base class ConnectAsyncResult object?   (Please see first attached figure, it explains it better).

So I try to basically "cast" the incoming object into a ConnectAsyncResult and I get an error "not accessible because it is 'Friend'.  SURELY there is a way to get at this error info, if I can watch it, I just can't seem to get the syntax right.

Thanks for any help.

watch.pngfriend.png
RonMexicoAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

SammyCommented:
I am not a VB guy but I think you should handle your exception in a try catch block
Private Sub ConnectCallback (byval Ar as IAsyncResult)
Try
'here is your code as is
Catch ex As Exception 'HERE you can find out the type of exception and handle it

End Try
End Sub
0
RonMexicoAuthor Commented:
I'd rather handle this particular condition directly, instead of using catch-all exception handling.  I prefer to use exception handling for off-normal ("exceptional") things.  The server being offline is a very normal condition.

But preferences aside, in any case there must be a way to get that ErrorCode info (since I can watch it) so I'd like to know the proper syntax.  I'll learn a lot from that answer since frankly I'm confused even about the relationship between ConnectAsyncResult and IAsyncResult.
0
SammyCommented:
I'd rather handle this particular condition directly, instead of using catch-all exception handling
Who said anything about a catch all handling?
The server being offline is a very normal condition.
No, not really, if the application is expecting the server to be online, then the server being offline is an exception to the norm.

Good luck.
0
Cloud Class® Course: MCSA MCSE Windows Server 2012

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

RonMexicoAuthor Commented:
You have no idea if my application can "expect" my server to be online.
0
RonMexicoAuthor Commented:
Okay... sorry I appreciate any thoughts.  

What I'd like to know is how to read that ConnectAsyncResult.ErrorCode programmatically.
0
Jaime OlivaresSoftware ArchitectCommented:
The ErrorCode property belongs to an internal class of the socket library. You shouldn't try to read it, although you can do it through reflection.
As mentioned above, your best chance is to trap the SocketException, which contains the error code.
0
Jaime OlivaresSoftware ArchitectCommented:
The reflection way (unrecommended) would be:

    Dim objType As Type = ar.GetType()
    Dim pInfo As System.Reflection.PropertyInfo = objType.GetProperty("ErrorCode")
    Dim PropValue As Object = pInfo.GetValue(obj, Reflection.BindingFlags.GetProperty, Nothing, Nothing, Nothing)
0
RonMexicoAuthor Commented:
Thank you very much,

"The ErrorCode property belongs to an internal class of the socket library. You shouldn't try to read it"

Would you mind expanding on this a little?  Why is it available to the debugger (as evidenced by it showing up in the watch) and not to my code?  (Explaining by reference to, say, an MSDN article is fine.)
0
Jaime OlivaresSoftware ArchitectCommented:
You are looking at the internal implementation of Microsoft, but as it is declared as an internal (aka Friendly) class, it is not intended to be used directly by the developers.
Although you can reach it by using reflection, there is not guarantee that this internal implementation will change in the future.
Formally, you should stick to the public classes only. In this case, by trapping the SocketException.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
.NET Programming

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.