Ссылаясь на Каков правильный способ создания настраиваемого .NET-исключения? и Являются ли все .NET-исключения сериализуемыми?...
Почему мои исключения могут быть сериализуемыми?
Кто-то сказал, что "это можно считать ошибкой", если настраиваемое исключение, определенное сторонней библиотекой, не является сериализуемым. Зачем?
Почему в этом отношении исключения отличаются от других классов?
Поскольку ваши исключения, возможно, должны быть распределены между различными AppDomains, и если они не являются (правильно) сериализуемыми, вы потеряете драгоценную информацию для отладки. В отличие от других классов, у вас не будет контроля над тем, будет ли выделено ваше исключение - оно будет.
Когда я имею в виду, "у вас не будет контроля", я имею в виду, что классы, которые вы создаете, обычно имеют ограниченное пространство существования, и существование хорошо известно. Если это возвращаемое значение, и кто-то пытается вызвать его в другом приложении AppDomain (или на другом компьютере), он получит ошибку и может просто сказать "Не используйте его таким образом". Вызывающий абонент знает, что он должен преобразовать его в тип, который может быть сериализован (путем переноса вызова метода). Тем не менее, поскольку исключения пузырятся до самого верха, если не пойманы, они могут преодолеть границы AppDomain, о которых вы даже не знали. Исключением для вашего обычного приложения 20 уровней в другом AppDomain может быть исключение, указанное в Main(), и ничто по пути не превратит его в сериализуемое исключение для вас.
В дополнение к ответу Talljoe, ваши исключения могут также передаваться через веб-службы, в этом случае исключение должно быть сериализуемым/десериализуемым, чтобы его можно было преобразовать в XML и передать веб-службой
Я думаю, что значение по умолчанию для всех классов должно быть Serializable, если они не содержат класс, который явно не сериализуется. Это раздражает, чтобы не быть способным передавать класс только потому, что какой-то дизайнер не думал об этом.
То же самое с "Финалом", все переменные по умолчанию должны быть "Финальными", если вы специально не заявляете, что они "Mutable".
Кроме того, я не уверен, что имеет смысл иметь переменную, которая не является частной.
Ну, мне нужно разработать собственный язык.
Но ответ заключается в том, что вы не знаете, как будет использоваться ваше исключение, и предполагается, что они могут быть переданы через удаленные вызовы.
Другое место, где объекты, подлежащие сериализации, - это сеанс Asp.Net. Мы сохраняем последнее исключение в сеансе, а не сериализуемые исключения нуждаются в дополнительном переводе, чтобы хранить их данные как сериализуемые (указание исходного исключения как внутреннего не помогает)