Project

General

Profile

Feature #917

birth, death and returning False

Added by Jackson, Mike about 12 years ago. Updated over 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Richards, Alexander
Category:
common_py
Target version:
Start date:
24 February 2012
Due date:
% Done:

100%

Estimated time:
Workflow:
In Development

Description

This is motivated from the issue of #896 and birth and death of workers in a MapPyGroup and a new version I've coded in 776 which copes with possible exceptions arising in birth and death of individual sub-workers. This solution is robust but rather involved due to birth and death returning False if they fail but also possibly throwing exceptions.

I'd propose changing birth and death to just throw an exception if they fail in any way. This then allows the framework, or other components, to decide how to handle these exceptions e.g. print an associated message.

To take the MapPyGroup example - returning False if the death of the MapPyGroup fails may conceal a multitude of errors arising from failures in the death of its individual members. The members themselves (e.g. individual mappers) should not be responsible for printing errors since that should be the responsibility of interface-specific components. This is why, for example, I force ErrorHandler to "raise" in the Celery worker so any errors arising can be passed back from the Celery worker machine to the Go.py framework.

Also available in: Atom PDF