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
>>
>
