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.