Вопрос по .net, exception – Почему я всегда должен делать свои исключения [сериализуемыми]? (.СЕТЬ)

37

Ссылаясь наКак правильно сделать сериализуемую пользовательскую исключительную ситуацию .NET исключительной?
а такжеВсе ли исключения .NET сериализуемы? ...

Why should my exceptions be serializable?
Кто-то сказал: «это можно считать ошибкой» если пользовательское исключение, определенное сторонней библиотекой, не сериализуемо. Зачем?

Почему исключения отличаются от других классов в этом отношении?

Ваш Ответ

4   ответа
51

и доменами приложений, и если они не будут (правильно) сериализуемы, вы потеряете ценную информацию об отладке. В отличие от других классов, вы не будете иметь контроль над тем, будет ли ваше исключение распределено - так и будет.

Когда я имею в виду «у вас не будет контроля» Я имею в виду, что классы, которые вы создаете, обычно имеют конечное пространство существования, и существование хорошо известно. Если это возвращаемое значение, и кто-то пытается вызвать его в другом домене приложений (или на другом компьютере), он получит ошибку и может просто сказать «не использовать его таким образом». Вызывающая сторона знает, что они должны преобразовать ее в тип, который можно сериализовать (оборачивая вызов метода). Однако, поскольку исключения всплывают до самого верха, если их не поймать, они могут выходить за границы домена приложения, о котором вы даже не подозревали. Исключение вашего пользовательского приложения на 20 уровней в другом домене приложений может быть исключением, сообщенным в Main (), и ничто по пути не превратит его в сериализуемое исключение для вас.

@Sam: NUnit по умолчанию создаст один или несколько отдельных доменов приложений, чтобы изолировать ваш код от самого бегуна NUnit, и разумно ожидать, что другие платформы модульного тестирования сделают то же самое.
Это действительно хороший ответ. Cheeso
Можете ли вы вспомнить конкретную ситуацию / пример, в котором это может произойти?
-1

где объекты должны быть сериализуемыми, - это Asp.Net Session. Мы сохраняем последнее исключение в сеансе, и не сериализуемые исключения нуждаются в дополнительном переводе, чтобы сохранить их детали как сериализуемые (указание исходного исключения как внутреннего не помогает)

Это звучит как причина, почему исключения должны быть sdrializable вyour вариант использования, но он не отвечает на общий вопрос.
@stakx, когда вы исправляете код, вы должны рассмотреть различные варианты использования, где он может быть использован
0

что по умолчанию для всех классов должен быть Сериализуемый, если они не содержат класс, который явно не сериализуем. Раздражает отсутствие возможности переносить класс только потому, что об этом не задумывался какой-то дизайнер.

То же самое с «Окончательным», все переменные должны быть «Окончательными» по умолчанию, если вы не укажете, что они являются «изменяемыми».

Кроме того, я не уверен, что имеет смысл иметь переменную, которая не является частной.

Ну да ладно, надо оформить свой язык.

Но ответ таков: вы не знаете, как будет использоваться ваше исключение, и предполагается, что оно может быть использовано при удаленных вызовах.

Исключения не должны делать это. Кроме того, у 3 классов, с которыми я сталкивался и хотел сериализовать в прошлом месяце (включая исключение), таких ограничений не было. Комитет по разработке неизменяемого API просто не определил это
@ Билл: в качестве альтернативы, дизайнерdid думать об этом, но решил не поддерживать сериализацию. Например, как бы использовать сериализовать класс, который содержит дескрипторы для собственных ресурсов, или даже просто открытые потоки?
Да, и что касается моего предложения по сериализации по умолчанию, если бы у вас были такие условия, ресурсы были бы помечены как "не сериализуемые". что приведет к тому, что ваш класс станет несериализуемым, если вы не пометите их как «временные», так что он будет работать нормально - лучше, чем текущая система.
У класса, который выдает исключение, есть разумное ожидание, что оно не будет сделано удаленным (поскольку я только что реализовал огромную вонючую кучу RMI, я могу сказать вам, что это не ВСЕГДА верно, но в целом это так). За исключением того, что вам нужно знать все классы выше, чтобы знать, что это правда. Сделав непроверяемое исключение сериализации, вы можете случайным образом нарушать удаленный код странным образом, практически не имея возможности выяснить, что произошло (на стороне клиента это может выглядеть так, будто ваш вызов никогда не вернется - никогда. Мне пришлось преследовать один из них вниз, это довольно WTF).
Интересные мнения. Я понимаю, что исключения предназначены для удаленного доступа, для чего требуется [сериализуемый]. Но как насчет второй части Q: почему исключения отличаются от любого другого класса? WRT [сериализуемый]? Класс, который выдает исключение, не сериализуем, и никто, похоже, не спорит с этим. Cheeso
0

через веб-службы, в этом случае исключение должно быть сериализуемым / десериализуемым, чтобы его можно было преобразовать в XML и передать веб-службой.

Джеффри: ты почти прав. Когда исключение «отправлено» через веб-сервис, не все обязательно сериализуются. Он фактически преобразуется в ошибку SOAP, поэтому полная точность не требуется. Кроме того, XML Serializer, используемый в старых сервисах ASMX, почти не обращает внимания на [Serializable].

Похожие вопросы