django: augmenter BadRequest que l'exception?

Vous avez besoin personnalisé middleware pour gérer exception de ce que vous vous levez.
Vous avez besoin pour des exceptions à vérifier dans le middleware.

class ErrorHandlingMiddleware(object):
    def process_exception(self, request, exception):
        if not isinstance(exception, errors.ApiException): # here you check if it yours exception
            logger.error('Internal Server Error: %s', request.path,
                exc_info=traceback.format_exc(),
                extra={
                    'request': request
                }
            )
        # if it yours exception, return response with error description
        try:
            return formatters.render_formatted_error(request, exception) # here you return response you need
        except Exception, e:
            return HttpResponseServerError("Error During Error Processing")

OriginalL'auteur coldmind

Comme une alternative à @coldmind réponse (conversion des exceptions dans une couche logicielle), vous pourriez mettre un décorateur sur votre point de vue de la fonction qui fait la même chose. Personnellement, je préfère cela, car c'est tout simplement le-vieux-Python, et ne pas exiger de moi de dépoussiérer ma connaissance de la façon dont Django middleware œuvres.

Vous ne souhaitez pas diffuser-de-la conscience inline toutes les fonctionnalités de votre point de vue fonctions (ce qui fait votre point de vue module dépendent tous de votre projet à d'autres modules, conduisant à "tout dépend de tout le reste' de l'architecture) au Lieu de cela, c'est mieux si la vue juste sait sur http. Il extrait ce dont vous avez besoin à partir de la demande, les délégués à certains autres "logique d'entreprise". La logique d'entreprise peut déléguer à d'autres modules (par exemple, code de base de données ou les interfaces avec d'autres systèmes externes.) Puis, finalement, la valeur de retour de votre logique métier est convertie en un http de la réponse par le point de vue de la fonction.

Mais comment communiquer les erreurs de retour à l'affichage de la fonction de la logique d'entreprise (ou de ce qu'il délègue à d')? En utilisant les valeurs de retour est gênant pour de nombreuses raisons. Par exemple, ces erreurs valeurs de retour devra être propogated retour à la vue de tous à travers l'ensemble de votre base de code. C'est souvent cripplingly malpropre parce que vous serez déjà en utilisant les valeurs de retour des fonctions à d'autres fins.

La façon naturelle de traiter cette question est d'utiliser des exceptions, mais la Django vue n'est pas, par elle-même, de convertir les exceptions non traitées dans HTTP renvoyé codes d'état (à l'exception de quelques cas particuliers, comme l'OP dit.)

. J'écris un décorateur d'appliquer à mon avis. Le décorateur convertit divers ont soulevé l'exception des types dans différents retourné django.http.HttpResponseXXX valeurs. e.g:

# This might be raised by your business logic or database code, if they get
# called with parameters that turn out to be invalid. The database code needs
# know nothing about http to do this. It might be best to define these exception
# types in a module of their own to prevent cycles, because many modules 
# might need to import them.
class InvalidData(Exception):
    pass

# This decorator is defined in the view module, and it knows to convert
# InvalidData exceptions to http status 400. Add whatever other exception types
# and http return values you need. We end with a 'catch-all' conversion of
# Exception into http 500.
def exceptions_to_http_status(view_func):
    @wraps(view_func)
    def inner(*args, **kwargs):
        try:
            return view_func(*args, **kwargs)
        except InvalidData as e:
            return django.http.HttpResponseBadRequest(str(e))   
        except Exception as e:
            return django.http.HttpResponseServerError(str(e))
     return inner

 # Then finally we define our view, using the decorator.

 @exceptions_to_http_status
 def myview(self, request):
     # The view parses what we need out of incoming requests
     data = request.GET['somearg']

     # Here in the middle of your view, delegate to your business logic,
     # which can just raise exceptions if there is an error.
     result = myusecase(data)

     # and finally the view constructs responses
     return HttpResponse(result.summary)

Selon les circonstances, vous pourriez trouver le même décorateur pourrait travailler à plusieurs, ou la totalité, de votre point de vue fonctions.

OriginalL'auteur Jonathan Hartley

Je ne suis pas sûr de ce que tu veux dire par le relèvement de BadRequest comme une exception.

Vous pouvez renvoyer une réponse avec n'importe quel code d'état que vous souhaitez, soit en utilisant explicitement le sous-classe pertinente de HttpResponse, ou par l'ajout d'un status paramètre de la réponse normale.

OriginalL'auteur Daniel Roseman