Changes between Version 1 and Version 2 of Ticket #29664, comment 2
- Timestamp:
- Aug 13, 2018, 9:47:50 AM (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #29664, comment 2
v1 v2 1 I'm afraid catching `TypeError` around the view callable execution is a too coarse net to have. what if the view (be it either a traditional function-based view, or a correctly invoked class based view via it's `.as_view()` method, etc.) result in a legitimate `TypeError`? Wouldn't the useful traceback that cold help the developer diagnose the issue be replaced by the new one that reports `"Check if as_view() method called properly"`?1 I'm afraid catching `TypeError` around the view callable execution is a too coarse net to have. What if the view (be it either a traditional function-based view, or a correctly invoked class based view via it's `.as_view()` method, etc.) results in a legitimate `TypeError`? Wouldn't the useful traceback that could help the developer diagnose the issue be replaced by the new one that reports `"Check if as_view() method called properly"`? 2 2 3 In the end there a line that needs to be placed between handholding a developer which face this kind of problems, and the expectation of them reading the relevant documentation, i.e.3 In the end there's a line that needs to be placed between handholding a developer which face this kind of problems, and the expectation of them reading the relevant documentation, i.e. 4 4 5 5 https://docs.djangoproject.com/en/dev/topics/class-based-views/#simple-usage-in-your-urlconf 6 6 https://docs.djangoproject.com/en/dev/topics/class-based-views/intro/#using-class-based-views 7 7 8 I'm ok with trying to be more helpful but not at the expense of reducing the usefulness of normal Python debugging techniques.8 I'm okay with trying to be more helpful but not at the expense of reducing the usefulness of normal Python debugging techniques.