Более изящная обработка исключений, чем несколько блоков выгоды? [дубликат]
class CustomerViewSet(viewsets.ModelViewSet):
"""Handle creating reading and updating Users in system"""
serializer_class = serializers.CustomerSerializer
#you are using customer model for serializer but for query set you are using
#User model.
queryset = models.Customer.objects.filter( user__type = "CS" )
authentication_classes = (TokenAuthentication,)
permission_classes = (permissions.UpdateCustomerProfile,)
8 ответов
In my opinion, a bunch of "ugly" catch blocks IS the best way to handle that situation.
The reason I prefer this is that it is very explicit. You are explicitly stating which exceptions you want to handle, and how they should be handled. Other forms of trying to merge handling into more concise forms lose readability in most cases.
My advice would be to stick to this, and handle the exceptions you wish to handle explicitly, each in their own catch block.
Я согласен с Ридом: это лучший подход.
Я бы добавил эти комментарии:
Только поймать то, с чем вы собираетесь что-то делать. Если вы не можете решить проблему, нет смысла перехватывать конкретное исключение.
Не переусердствуйте с использованием блоков перехвата. Во многих случаях, когда вы не можете разрешить исключение, лучше просто позволить исключению всплыть до центральной точки (например, Page_Error) и перехватить его там. Затем вы регистрируете исключение и отображаете сообщение для пользователя.
Единственное, что вы можете сделать, это эмулировать фильтры исключений VB.NET:
try {
DoSomething();
} catch (Exception e) {
if (!ex is CustomException && !ex is AnotherCustomException) {
throw;
}
// handle
}
Иногда это лучше, иногда нет. Я бы в основном использовал его, если бы в обработчике была какая-то общая логика, которую я хотел, но исключения не разделяют базовый тип.
Unfortunately, C# does not have user exception filters like VB.NET, so you're limited to:
- Catching a common ancestor to all exceptions. This may or may not be what you want, because there may be other descendant exception types that you do not want to catch.
- Moving the exception handling logic into another method and calling that from each handler.
- Repeating the exception logic for each handler.
- Moving the exception handling logic into a language that supports filters, such as VB.NET.
Если вам нужно написать действительно большое количество кода, как это, я бы предложил проверить некоторые AOP рамки. Я лично использую PostSharp . Тогда вы можете скрыть весь код обработки исключений в аспектах.
Вам следует обратиться к Корпоративной библиотеке Блок обработки исключений . Он позволяет гораздо более точно контролировать зерно исключений с помощью политик (политики обертывания, политики распространения, политики замены, политики ведения журнала и т. Д.). Вы можете использовать его для стандартизации способа кодирования блока исключений и использования конфигурации для точной обработки того, что происходит с особый тип исключения.
Разве это не хорошо?
Если вы хотите обработать только одно исключение:
try
{
// Many types of exceptions can be thrown
}
catch (TheExceptionIWantToHandle ex)
{
// handle it
}
catch (Exception ex)
{
// suppress all other exceptions
}
Если вы хотите обработать все исключения, кроме одного:
try
{
// Many types of exceptions can be thrown
}
catch (TheExceptionIDoNotWantToHandle ex)
{
// suppress all other exceptions
}
catch (Exception ex)
{
// handle it
}
хорошо, не хорошо?
Поймайте только то, что вам нужно разрешить специально, и оставьте
catch(Exception e)
{
}
для всего остального (или пропустите его и передайте это исключение в стек)