Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Checking exception types
#1
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.
Reply
#2
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.
Dean Roddey
Explorans limites defectum
Reply
#3
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?
Reply
#4
You can do that, yeh. Catch your own 'lost connection' exception at the outermost level and return the appropriate indicator there.
Dean Roddey
Explorans limites defectum
Reply
#5
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?
Reply
#6
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.
Dean Roddey
Explorans limites defectum
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Unhandled system exception in the GUI Thread gReatAutomation 9 2,270 03-23-2020, 01:03 PM
Last Post: Dean Roddey
Photo Unhandled GUI Exception simplextech 3 1,282 01-05-2020, 03:27 PM
Last Post: zra
  Unhandled system exception in GUI Thread Shaky 75 20,844 06-21-2019, 08:10 PM
Last Post: kblagron
  Syntax checking Ron Haley 5 2,461 09-19-2016, 08:26 PM
Last Post: Dean Roddey
  Unhandled Exception Scheduled Events zra 8 4,104 06-25-2015, 05:54 PM
Last Post: zra
  An unknown exception has occured... brathnach 11 4,490 11-10-2013, 06:08 PM
Last Post: brathnach
  FileOutStream Exception wuench 3 2,002 12-29-2012, 08:15 PM
Last Post: Dean Roddey
  New Exception Behavior 4.2.16? wuench 1 1,477 11-19-2012, 12:52 PM
Last Post: Dean Roddey
  unhandled exception Ron Haley 3 1,655 11-13-2012, 08:55 PM
Last Post: Dean Roddey
  Checking for a rejected Elk arm/disarm Dean Roddey 2 1,644 07-12-2012, 02:28 PM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)