The NameError use case on the docs Danny linked is another example of this
being unclear and introducing highly unexpected behavior.
On Jan 27, 2013 7:02 AM, "Cory Zue" <czue@dimagi.com> wrote:

> My understanding of the issue is that if you catch one of the termination
> conditions the exception gets swallowed so you don't just "finish and
> exit", you finish and don't exit, which is pretty sketchy. Are you saying
> it works differently?
>
> Catching Exception is totally fine and standard practice... And you can
> add GreenletExit to that if you want those too.
> On Jan 26, 2013 11:46 PM, "Mike White" <notifications@github.com> wrote:
>
>> In corehq/apps/reports/models.py:
>>
>> > @@ -330,9 +339,12 @@ def get_report_content(self):
>> >
>> >          request.GET = QueryDict(self.query_string + '&filterSet=true')
>> >
>> > -        response = self._dispatcher.dispatch(request, render_as='email',
>> > -                                             **self.view_kwargs)
>> > -        return json.loads(response.content)['report']
>> > +        try:
>> > +            response = self._dispatcher.dispatch(request, render_as='email',
>> > +                **self.view_kwargs)
>> > +            return json.loads(response.content)['report']
>> > +        except:
>>
>> Bottom line, if the process/thread/eventlet/whatever that sends an email
>> ever exits without sending the email and doesn't somehow queue the task to
>> be retried with some reason to suspect that it will eventually succeed, no
>> scheduled report email will ever be sent, and that's a bug. I don't even
>> get how this throwing of exceptions "into" things works, but when would
>> whatever does that not be able to handle it if it was caught?
>>
>> I guess if you had a scheduled report with three report configs that each
>> took 500 seconds to generate the report for, and something tried to kill a
>> task after 100 seconds, then if it was caught and execution continued and
>> the something that tried to kill it didn't then throw another exception
>> into it after another 100 seconds, you could end up with a ballooning queue
>> or something?
>>
>> —
>> Reply to this email directly or view it on GitHub<https://github.com/dimagi/core-hq/pull/506/files#r2786070>.
>>
>>
>