C# - Почему конструкторы исключения стандарта реализации?
Хотя вы упомянули, что вы не можете использовать исключение в вашем случае, я думаю, что другие, которые встречают этот ответ (например, я, основываясь на названии), могут найти его полезным.
Можно выборочно скрывать поля, используя exclude в ModelAdmin, вот фрагмент из того, над чем я работаю:
class ItemsAdmin(admin.ModelAdmin):
form = ItemsForm
actions = None
list_display = ('item_id', 'item_type', 'item_title', 'item_size', 'item_color',)
search_fields = ('item_id', 'item_title',)
inlines = [ImageInline,]
readonly_fields = ('disable_add_date','disable_remove_date',)
exclude = ('add_date', 'remove_date',)
###.............
5 ответов
Это предупреждение, а не требование. По сути, это принцип наименьшего удивления . Предоставление всех 4 упрощает людям, привыкшим к "обычным" исключениям C #, использование ваших. Если у вас есть веская причина игнорировать это руководство, сделайте это. Но это нарушит определенные сценарии использования и сделает ваш класс менее интуитивным.
Вы получили хорошие ответы. Я просто хочу добавить, что предоставление этих дополнительных конструкторов не обязательно требует большого количества кода. Поскольку они уже реализованы в базовом классе, вы можете просто позволить ему выполнять работу:
public class MyCustomException : Exception
{
public MyCustomException() : base() { }
public MyCustomException(string message) : base(message) { }
public MyCustomException(string message, Exception innerException) : base(message, innerException) { }
// and so on...
}
Таким образом, вам нужно будет реализовать только код, в котором поведение вашего исключения отличается от поведения базового класса.
Конструкторы без параметров и сериализации используются общим кодом «маршрутизации исключений», который должен перемещать исключения между доменами (например, через Интернет между службой и клиентом).
которое принимает другое исключение , чтобы можно было связать все исключения через свойство InnerException .
Наконец, есть одно, которое принимает строку сообщения, что помогает использовать исключений достаточно последовательны.
Реализация стандартных конструкторов исключений позволяет людям использовать ваше исключение стандартным, знакомым способом, встроенным во все существующие исключения .NET. Первые три могут быть необязательными, если по какой-то причине вы не хотите, чтобы один из них использовался (хотя зачем вам это нужно, я не могу понять.) Однако последний - конструктор десериализации, и если вы хотите ваше исключение должно поддерживаться в любой распределенной среде (.NET Remoting, ASP.NET Web Services, WCF и т. д.), тогда это очень важно.
Без конструктора десериализации и атрибута [Serializable] ваши исключения не будут работать в распределенной среде и могут вызвать другие проблемы. Учитывая это, а также аспект знакомства для хорошо разбирающихся в C # разработчиков, лучше всего реализовать по крайней мере 4 стандартных конструктора исключений и пометить исключения с помощью [Serializable].
Что ж, конструктор, который принимает внутреннее исключение, в значительной степени необходим для правильного использования настраиваемого исключения. Без него, если кто-то поймает ваше исключение, он не сможет запустить более описательное или подходящее исключение, сохранив ваше исходное (и информацию, которую он несет, например трассировку стека).