I guess the question is what value does does the broadness have? Also
knowing where it is called now doesn't necessarily mean it won't get called
in other places in the future. It's also totally theoretically possible
that some interrupt exception could get called and swallowed via celery or
django. I don't understand the downside.


On Sat, Jan 26, 2013 at 5:28 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:
>
> I also don't see why it shouldn't catch any other exception that was
> raised and send the email report with an error message for that report
> rather than fail to send the entire email report.
>
> The two places where this is currently called from are the scheduled
> report preview view in the django process and the reporting sending celery
> task. Seems like a bare except: isn't incorrect behavior for any scenario I
> can think of.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/dimagi/core-hq/pull/506/files#r2785537>.
>
>