I think the intent of exit_fail() is to try to close the connection, ignore any exceptions raised while trying to close the connection, and then re-raise the original exception that happened before exit_fail was called, but I think the implementation is flawed. Here’s the definition of exit_fail() as it appears on GitHub:
def exit_fail(): print 'FAILURE DETECTED. Log entries:\n',lh.printMessages() try: fpga.stop() except: pass raise exit() I think this try/except block (with "pass" in the except part) followed by "raise" is completely superfluous. I think it means try to do something and if an exception is raised while trying, ignore it but then re-raise it, which seems exactly the same as not having the try/except block there at all! Not to mention that the exit() call will never be reached. I’m also not a fan of functions that can only be called while an exception is being handled (otherwise the no-arg form of "raise" will bomb out I think). It would probably be preferable to pass the original exception to exit_fail() as an argument so that the original exception can be re-raised. I can make that change when I get back to Berkeley next week (unless someone beats me to it). Sorry for veering so far off topic, Dave > On Oct 11, 2016, at 10:16, Jason Manley <jman...@ska.ac.za> wrote: > > Some of the earlier scripts had bad error handling. If anything fails before > the host object was successfully created, then you get this error because it > tries to close the connection before exiting. > > Jason > > On 11 Oct 2016, at 16:09, David MacMahon <dav...@berkeley.edu> wrote: > >> >>> On Oct 11, 2016, at 06:46, Heystek Grobler <heystekgrob...@gmail.com> wrote: >>> >>> Connecting to server 192.168.33.7 on port 7147... FAILURE DETECTED >> >> Editorial comments on error handling in tut3.py aside, I think the fact that >> "FAILURE DETECTED" follows "Connecting to server…" on the same line (i.e. no >> newline character inbetween) means that something went wrong when >> constructing the FpgaClient object which connects to TCP port 7147 of the >> ROACH2 with IP address 192.168.33.7. This is expecting the ROACH2 to have a >> tcpborphserver process listening on that port. >> >> What happens when you run: >> >> telnet 198.168.33.7 7147 >> >> HTH, >> Dave >> >