Checking exception types

[beelzerob]

I'm dealing with converting a good portion of my drivers to either IP or serial. One of the challenges in that is to make sure I can break out of however deep I am if I have suddenly lost the socket connection, since the only thing that will fix that is a LostCommRes result.

If I catch an exception, I want to deal with it unless its a SocketErrors exception, in which case I want to rethrow it.

A given Try/Catch block can cover a ton of code and catch numerous different exception enumeration types. There is no function for checking if the exception is specifically a SocketErrors exception...only for testing a value within that enumeration. So, if I check that the exception is CheckGreater than the SocketErrors.NotConn, but the exception isn't even a SocketErrors exception (maybe it was a bad index into an array), will it still work correctly? Basically, will the CheckGreater always return false if the $Exception isn't of the enumerated type you're comparing it to? That *SHOULD* be correct, but I'm just checking.

[Dean Roddey]

Don't try to guess, use the GetIsConnected() method to test whether the socket is still connected or not. If not, you lost it. On the client side, the only way you'll get a socket error is because you are trying to talk to the server. As long as you are trying to talk, if the connection is lost, then it'll show not connected. It's more complicated on the server side, but since the client is always try to send and receive, any loss of connection should cause that method to return false.

[beelzerob]

So, in any catch block that could have caught a socket errors exception, do an IsConnected() check on the socket? And if its no longer connected, then I guess throw my own enumerated exception type to have it wind all the way out?

[Dean Roddey]

You can do that, yeh. Catch your own 'lost connection' exception at the outermost level and return the appropriate indicator there.

[beelzerob]

Ok, well that's useful to know, and I *will* do that. But I'm still curious how the CheckGreater works given that the $Exception could be a SocketErrors exception, a NamedValMapErrs exception, etc. I take it that the CheckGreater takes into account the enumerated type when checking the "greater than"-edness?

In other words, it's not a simple ordinal check, right?

[Dean Roddey]

It insures that the enumeration types are the same, and then it knows it can do an ordinal comparison since they are of the same type.