Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update views.py #21

Closed

Conversation

maljuboori91
Copy link

Instead of raising an error and return 500 server error, just send pretty response with 400 HTTP status error and let the client know the email doesn't exist!

Instead of raising an error and return 500 server error, just send pretty response with 400 HTTP status error and let the client know the email doesn't exist!
@anx-ckreuzberger
Copy link
Contributor

Thank you for the PR!

I believe that there is a nicer way of implementing this. Would you like to try that out? That would be nice!

I think that with Django Rest Framework you can do the following:

from rest_framework.serializers import ValidationError # instead of from django.core.exceptions import ValidationError

# ...
def some_func:
    if something_wrong:
        raise ValidationError({
            'email': ValidationError(
                _("There is no active user associated with this e-mail address or the password can not be changed"),
                code='invalid')}

This should trigger a status code 400 (instead of the internal server error with status 500).

Also, please make all strings "translateable" by using the _(...) function (it is imported as from django.utils.translation import ugettext_lazy as _).

@anx-ckreuzberger
Copy link
Contributor

Hi,

I've digged deeper into this problem and found that the "old" way of raising the ValidationError was basically fine, but it needed a different import.
I've changed the import from

from django.core.exceptions import ValidationError

to

from rest_framework.exceptions import ValidationError

and added a test that checks for status 400 and a proper error message in PR #24.
I'm closing this in favour of #24.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants