Changes between Version 1 and Version 2 of Ticket #29664, comment 2


Ignore:
Timestamp:
08/13/18 14:47:50 (4 years ago)
Author:
Ramiro Morales
Comment:

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"`?
     1I'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"`?
    22
    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.
     3In 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.
    44
    55https://docs.djangoproject.com/en/dev/topics/class-based-views/#simple-usage-in-your-urlconf
    66https://docs.djangoproject.com/en/dev/topics/class-based-views/intro/#using-class-based-views
    77
    8 I'm ok with trying to be more helpful but not at the expense of reducing the usefulness of normal Python debugging techniques.
     8I'm okay with trying to be more helpful but not at the expense of reducing the usefulness of normal Python debugging techniques.
Back to Top