django - 是否应该捕获来自 HTTP 参数问题的不可恢复异常？

Question

是否有必要捕获源自 HTTP 输入的错误？让它自然失败(允许异常冒泡)是个好主意吗？

我有一个用于 AJAX 调用的服务器端接口(interface)的 Django View ，看起来像这样:

def some_view(request):
    try:
        some_int = int(request.POST.get('some_int')) # May raise ValueError or TypeError
    except (ValueError, TypeError):
        return HttpResponseBadRequest('some_int must be an int')
    # ... Code that assumes some_int is an int
    return HttpResponse('The normal response')

在生产代码中是否可以接受这样的东西？

def some_view(request):
    some_int = int(request.POST.get('some_int')) # Ignore ValueError or TypeError raised
    # ... Code that assumes some_int is an int
    return HttpResponse('normal_response')

当我接受更多参数时，我发现维护这么多大部分相同的 try/except block 令人沮丧，我最终得到大量样板代码。

当然，我试图将其重构为一个单独的函数，但由于 Django 需要返回一个 HttpResponse，而不是作为异常引发，所以我无法在不尝试的情况下将其插入 View /除了 block 。此外，转换为 int 并不是我检查的唯一内容……还有很多业务逻辑健全性检查也根据输入执行。例如，我会验证传递的 JSON 是否具有特定格式(即 int 数组的对象数组等)。

我的观点最终只有 70 多行代码仅用于健全性检查和几行实际生成响应的代码。不知何故，我觉得应该有一种更优雅的方式，但我还没有找到，所以我正在考虑放弃所有检查，让 Django 来处理它。 这是个坏主意吗？

如果我不捕获异常，我知道以下潜在问题:

1. 为所有错误返回相同的 HTTP 500
2. 如果在生产中启用日志记录，它可能会在每次出现无效输入时记录错误

还有其他我应该注意的问题吗？不捕获用户输入的异常感觉是错误的，即使在恢复逻辑方面我无能为力。

Answer 1

我认为处理此问题的最佳方法是编写您自己的 middleware捕获异常并将它们变成您想要的响应。

这可能看起来像这样:

# views.py
def some_view(request): 
    some_int = int(request.POST.get('some_int'))
    # ... Code that assumes some_int is an int
    return HttpResponse('normal_response')


# middleware.py
class MyValidationMiddleware(object):
    def process_exception(self, request, e):
        if isinstance(e, ValueError):
            return HttpResponseBadRequest('Input did not validate')
        else:
            return None  # let it bubble up

(由于中间件是站点范围的，您可能希望明确定义您自己的输入验证异常，以将它们与可能发生的其他类型的异常区分开来。)

或者，您可以使用 per-view 装饰器做同样的事情。