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
if expected_key is not in request.GET:
return MyErrorResponse(...)
if not request.GET.get("expected_key", None):
return MyErrorResponse(...)
required = ["one", "two", "three", "four"]
if not all(k in request.GET.keys() for k in required):
return MyErrorResponse(...)
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 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']
> except MultiValueDictError:
> return response("Missing user data 'x'", status=404)
> try:
> y = request.GET['y']
> except MultiValueDictError:
> return response("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 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/2423f3eb-e656-4084-a9c3-94e1ea41e969%40googlegroups.com.
