Tom, you're right about the second and third points though. If the user perform any operation with side effect that requires writing to the database before the view checks whether the keyword arguments are appropriate and decide to raise DoesNotResolve, it can definitely be a source of non-obvious bugs and surprising behaviour. For example, a counter increment in the view to count how many times the view has been visited, placed before checking for whether to raise DoesNotResolve. Multiple such views get executed, multiple view counters incremented for one HTTP connection.
I can only think of adding a stern warning to the documentation something along the lines of "Must not perform any operation requiring a database write or any other operation with side effects before the check for DoesNotResolve is made.". Eric On Thursday, March 28, 2013 3:28:10 AM UTC+11, Tom Christie wrote: > > * A `UrlNotMatched` exception sounds like the potential source of > incredibly non-obvious bugs and surprising behavior. > * Allow a single HTTP call to end up calling into multiple views just > seems like it would a fundamentally bad design decision. > > I really don't see the trade-off of allowing this type of behavior to be > worth the cost of breaking the current mental model of what a view is and > does. > > Just my personal opinion of course :) > > Tom > >> >> > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
