On Sun, Oct 14, 2012 at 12:38 PM, Terry Reedy email@example.com wrote:
On 10/14/2012 1:42 PM, Guido van Rossum wrote:
On Sun, Oct 14, 2012 at 10:27 AM, Terry Reedy firstname.lastname@example.org wrote:
On 10/14/2012 10:36 AM, Guido van Rossum wrote:
Of course there's the question of what to do when one of the tasks raises an error -- I haven't quite figured that out in NDB either, it runs all the tasks to completion but the caller only sees the first exception. I briefly considered having an "multi-exception" but it felt too weird -- though I'm not married to that decision.
One answer is to append the exception object to results and let the requesting code sort out what to do.
def par(*args): results =  for task in args: try:
result = yield from task results.append(result) except Exception as exc: results.append(exc) return results
But then the caller would have to sort through the results and check for exceptions. I want the caller to be able to use try/except as well.
OK. Then ...
def par(*args): results =  exceptions = False for task in args: try: result = yield from task results.append(result) except Exception as exc: results.append(exc) exceptions = True if not exceptions: return results else: exc = MultiXException() exc.results = results raise exc
Is this is what you meant by 'multi-exception'?
try: results = <whatever> <process results, perhaps by iterating thru them, knowing all represent successed> except MultiXException as exc: errprocess(exc.results)
In NDB I have yet to encounter a situation where I care.