STDOUT WorkflowException issue

Ok… stay with me here. I have a framework that interacts with different ‘node servers’ via STDIN and STDOUT and some other stuff.

I’m using your LIFXLAN module inside one of these node servers and it queries the light every 30 seconds. It creates a new class for each light and runs as a daemon.

My specific issue:

lifx = lifxlan.LifxLAN(None)
devices = lifx.get_lights()
for d in devices:
    while True:
        try:
            power = True if d.get_power() == 65535 else False
        except (lifxlan.device.WorkflowException):
            print 'The device is offline'
        time.sleep(30)

When I try to catch lifxlan.device.WorkflowException, no matter what I do it ALWAYS outputs to STDOUT. This actually breaks my framework. Instead of actually catching the exception, I get this to STDOUT:

WorkflowException: Did not receive <class 'lifxlan.msgtypes.LightStatePower'> in response to <class 'lifxlan.msgtypes.LightGetPower'>

My question is how the heck can I catch your custom exception from device.py without outputting to STDOUT? I’m sure it’s my ignorance, hope this is an easy question and I’m just missing something.

[mclarkk]

The issue is in light.py:

def get_power(self):
        try:
            response = self.req_with_resp(LightGetPower, LightStatePower)
            self.power_level = response.power_level
        except WorkflowException as e:
            print(e)
        return self.power_level

I changed print(e) to pass and that stopped the message from printing, surprise surprise. Of course, the better design would be to raise all the way up through the module to the user’s code, because the user may want their application logic to be different if the light goes offline.

There are actually a lot of places where the lifxlan code either silently catches an error or prints out the error message, which I agree is really obnoxious as a user. I’ll go through the code base and turn all those into re-raises. Then your code would be able to catch and handle the WorkflowException.

Thanks for pointing this out, in retrospect those were some pretty silly design decisions on my part. I’ll go through and make sure everywhere in the module where something gets printed out, it is only when the verbose flag has been intentionally set by the user.

[Einstein42]

I was very slow to respond on this. I really appreciate your efforts. This is an absolutely fantastic module.