Just because your code repeated in each and every form can be eliminated
and we can check it all in one place,
shortening code, eliminating duplication, reducing possibilities of errors.
On 09/02/2020 12:45, Steven Mapes wrote:
Perhaps I'm totally missing the point and use case for this but is
there any reason you are not simply using any of these
|
ifexpected_key isnotinrequest.GET:
returnMyErrorResponse(...)
|
|
ifnotrequest.GET.get("expected_key",None):
returnMyErrorResponse(...)
|
|
required =["one","two","three","four"]
ifnotall(k inrequest.GET.keys()fork inrequired):
returnMyErrorResponse(...)
|
I've used the latter approach if I have required parameters in a
GET/POST and I'm not using forms. I just adding the check to a base
view and having required
be an attribute
On Sunday, 9 February 2020 05:15:01 UTC, Victor Porton wrote:
In https://code.djangoproject.com/ticket/31239
<https://code.djangoproject.com/ticket/31239> I proposed to create
QueryDictKeyError derived from MultiValueDictKeyError and raise
this exception on a missing parameter in request.GET and request.POST.
It is to be done to handle error in user data easily:
|
try:
x =request.GET['x']
exceptMultiValueDictError:
returnresponse("Missing user data 'x'",status=404)
try:
| y =request.GET['y']
exceptMultiValueDictError:
returnresponse("Missing user data 'y'",status=404)
|
|
is much more cumbersome and error-prone than:
|
def handle_exception(self, exc):
if isinstance(exc, QueryDictKeyError):
# It is an unwise assumption that this is necessarily missing
HTTP param,
# but rewriting it in other way would be time consuming (and
maybe even more error prone).
return MyErrorResponse({"code": "PAR_1", "message": "Missing
param.", "field": exc.args[0]})
|
The latter may be added to a base view to handle such errors in
the entire project easily.
This handle_exception() could be even integrated into the core of
Dajngo to handle such errors automatically without the user
writing this code manually repeatedly.
Moreover, the above code is much more maintenable, as no need to
change error messages in each and every view, if a user wants to
change the error message.
Programming is about automation and we need the task about
handling user input errors to be done automatically.
@felixxm claims "Creating a single method to catch and handle all
kind of exceptions is error prone."
But the reverse things is true: not handling exception
automatically leads to many code errors.
@felixxm's claim as valid as "use CGI instead of Django: using a
CMS is error-prone, specify in the code exactly what you want
rather to relying to a single method."
If code can be simplified, it needs to be simplified.
Please support my feature request.
||
||
--
You received this message because you are subscribed to a topic in the
Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/django-developers/SIl46zbIdIc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
django-developers+unsubscr...@googlegroups.com
<mailto:django-developers+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/2423f3eb-e656-4084-a9c3-94e1ea41e969%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/2423f3eb-e656-4084-a9c3-94e1ea41e969%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/729ddf70-4bfe-e72e-1652-35b1d2e2cee4%40narod.ru.
