Project

General

Profile

Feature #917

birth, death and returning False

Added by Jackson, Mike over 9 years ago. Updated almost 9 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.

#1

Updated by Rogers, Chris over 9 years ago

Completely agree - really don't like returning False, much prefer exceptions...

#2

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?

#3

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.

#4

Updated by Richards, Alexander over 9 years ago

Fine, simple change at this stage.

#5

Updated by Rogers, Chris over 9 years ago

  • Assignee changed from Rogers, Chris to Richards, Alexander
  • Target version set to Future MAUS release
  • Workflow changed from New Issue to In Development
#6

Updated by Rogers, Chris almost 9 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100
#7

Updated by Rogers, Chris almost 9 years ago

  • Target version changed from Future MAUS release to MAUS-v0.4.0

Also available in: Atom PDF