Strategies to handle exceptions in actor run results beyond returning None?

[Dan Helyar]

Take the following code:

tasks.py

async def task_that_raises_exception(actor):
    return actor.attribute_which_does_not_exist

test_tasks.py

class TestThatShouldFail(ActorTestMixin, TestCase):
    async def test_task_that_raises_exception(self):
        proxy = await self.spawn_actor()
        with self.assertRaises(AttributeError) as cm:
            await send(proxy.aid, 'run', task_that_raises_exception)

This gives the output:

2017-08-10 07:20:24 pulsar.actor.ERROR - Unhandled exception
Traceback (most recent call last):
  File "/virtualenv/project/lib/python3.5/site-packages/pulsar/async/mailbox.py", line 229, in _on_message
    self)
  File "/virtualenv/project/lib/python3.5/site-packages/pulsar/async/mailbox.py", line 84, in command_in_context
    result = await result
  File "/var/www/project/tasks.py", line 110, in task_that_raises_exception
    return actor.attribute_which_does_not_exist
AttributeError: 'Actor' object has no attribute 'attribute_which_does_not_exist'


FAIL: tasks.test_task_that_raises_exception (var.www.project.tasks.TestThatShouldFail)
----------------------------------------------------------------------
Traceback (most recent call last):


  File "/virtualenv/project/lib/python3.5/site-packages/pulsar/apps/test/runner.py", line 225, in store_trace
    await coro


  File "/var/www/project/test_tasks.py", line 38, in test_task_that_raises_exception
    await send(proxy.aid, 'run', task_that_raises_exception)


  File "/usr/lib/python3.5/unittest/case.py", line 198, in __exit__
    self._raiseFailure("{} not raised".format(exc_name))


  File "/usr/lib/python3.5/unittest/case.py", line 134, in _raiseFailure
    raise self.test_case.failureException(msg)

AssertionError: AttributeError not raised

I suppose one way might be to try/except within the task itself, and return the exception. However it feels like this might be something the framework offers, and so I was wondering if there's any built in mechanism for this?

Thanks!

[lsbardel]

Hi,
good question :-)

On Thursday, August 10, 2017 at 8:26:28 AM UTC+1, Dan Helyar wrote:

snip

 

This gives the output:

2017-08-10 07:20:24 pulsar.actor.ERROR - Unhandled exception
Traceback (most recent call last):
  File "/virtualenv/project/lib/python3.5/site-packages/pulsar/async/mailbox.py", line 229, in _on_message
    self)
  File "/virtualenv/project/lib/python3.5/site-packages/pulsar/async/mailbox.py", line 84, in command_in_context
    result = await result
  File "/var/www/project/tasks.py", line 110, in task_that_raises_exception
    return actor.attribute_which_does_not_exist
AttributeError: 'Actor' object has no attribute 'attribute_which_does_not_exist'

This error is raised in the actor domain, and I think this is the correct behaviour. The actor has an handled error and log the exception, without crashing.

 

FAIL: tasks.test_task_that_raises_exception (var.www.project.tasks.TestThatShouldFail)
----------------------------------------------------------------------
Traceback (most recent call last):


  File "/virtualenv/project/lib/python3.5/site-packages/pulsar/apps/test/runner.py", line 225, in store_trace
    await coro


  File "/var/www/project/test_tasks.py", line 38, in test_task_that_raises_exception
    await send(proxy.aid, 'run', task_that_raises_exception)


  File "/usr/lib/python3.5/unittest/case.py", line 198, in __exit__
    self._raiseFailure("{} not raised".format(exc_name))


  File "/usr/lib/python3.5/unittest/case.py", line 134, in _raiseFailure
    raise self.test_case.failureException(msg)

AssertionError: AttributeError not raised

If we raise another exception in the arbiter domain we will end up having two stack traces pointing to the same error in the logs, and we don't want that. 

I suppose one way might be to try/except within the task itself, and return the exception. However it feels like this might be something the framework offers, and so I was wondering if there's any built in mechanism for this?

No there isn't, but I can see a reason to return something which indicates a failure.

Do you have a use case for needing this?

 

[Dan Helyar]

Thanks for the reply. Your answers make sense.

My use case is unit testing.