When trying to close an open connection, manually (Socket.Shutdown() Socket.Close()), wierd exceptions will get thrown in my callback subs (usually in the callback for receive, but sometimes other areas). Am I suppost to put a try/catch statement everywhere I try to use the socket? That just seems messy. :-/
TIA.
Try/catch is the appropriate way to do this as Socket calls do not return error codes.
Thank you. :)
As a side note, Try/Catch is appropriate for nearly everything you write, to gracefully handle unexpected situations without having to crash the user. It's not a replacement for data validation, logic, and program structure, so don't let us Catch you Trying to use it those ways! :P
Quote from: Grok on April 26, 2007, 09:09 AM
As a side note, Try/Catch is appropriate for nearly everything you write, to gracefully handle unexpected situations without having to crash the user. It's not a replacement for data validation, logic, and program structure, so don't let us Catch you Trying to use it those ways! :P
Going on that, published Best Practices indicate that you shouldn't just "catch (Exception ex)" - you should try to be specific about the exceptions you catch according to the ones that can be raised.
Having said so, there are certainly places where it's appropriate to do so.
So what would be the most appropriate block of code (take this very generally, not just for this example):
Private Sub DoStuff(ByVal variableOne As String, ByVal variableTwo As String)
Try
If variableOne Is Nothing Or variableTwo Is Nothing Then
'-- Display error code
Exit Sub
End If
'-- DoSomeStuff
'--
'--
'--
SomeSocketMethod()
Catch ex As Exception
'-- Handle Exception
End Try
End Sub
Or:
Private Sub DoStuff(ByVal variableOne As String, ByVal variableTwo As String)
If variableOne Is Nothing Or variableTwo Is Nothing Then
'-- Display error code
Exit Sub
End If
'-- DoSomeStuff
'--
'--
'--
Try
SomeSocketMethod()
Catch ex As Exception
'-- Handle Exception
End Try
End Sub
I would stick with the latter. Sanitizing/validating input is a very good practice to have in order to prevent security holes from cropping up. Check your design, too, to see if it would be appropriate to throw an ArgumentException (or derived class).
I've wondered if you can nest these? Try/catch into a procdure that has another try/catch it?
Isn't there a GetLastError function somewhere you can call to get some data on it?
get data on ex? This might be wrong, but have you tried stack trace. Ive found it useful in asp.net and just learned another way to use in in vb.net. it might have what you need.