birth, death and returning False
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.
Updated by Rogers, Chris over 9 years ago
Note I added Alex as a watcher - he is making a set of generic interface classes for the API in #907. I think this should either be his task or Alex implements what we have right now and then we change to exception handling as an "add-on". What do you think?
Updated by Jackson, Mike over 9 years ago
It'd be preferable if this was factored in from the outset of the API change otherwise it incurs additional overhead - once when porting what is there, then when changing it to have exceptions. It's preferable to get the API right now, then minimise the need for future changes to it.