Что не является причиной для создания пользовательского исключения?

Question

Недавно я сдал тест на мозговом стенде и получил неплохой результат (что-то вроде 4,5, степень магистра). Я не знал ответа только на 1 вопрос (в остальном я был уверен или, по крайней мере, думал, что знаю правильный ответ :)). Вопрос:

Что из перечисленного НЕ является причиной для создания пользовательских исключений?

Вариант 1
Чтобы вставить прочный ярлык для последующего осмотра
Вариант 2
Чтобы строго указать цель конкретного исключения
Выбор 3
Чтобы разрешить удаленную сериализацию
Вариант 4
Обработка общих шагов при создании исключения
Выбор 5
Добавление пользовательских свойств для пользовательского распространения данных

Я ответил «4» - для обработки общих шагов при создании исключения. Какой из них вы считаете правильным?

Answer 1

Вариант 3. Базовое исключение либо уже поддерживает удаленное взаимодействие, либо вы извлекаете из него добавление удаленное взаимодействие.

---

«Исключение», которое Марк упоминает в комментарии, выглядит следующим образом; Я думаю, что это не то, что имели в виду авторы тестов:

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

Лучше было бы распознавать определенные наборы исключений и преднамеренно переводить их в ошибки SOAP. Например, служба, которая работает с объектами базы данных, может ожидать, что иногда объект не будет найден; иногда попытка добавить новый объект может привести к дублированию; иногда попытка обновления привела бы к неверному состоянию. Такой сервис может решить выставить NotFoundFault, DuplicateItemFault и InvalidStateFault.

Служба будет определять три ошибки как контракты данных для определения их содержимого:

[DataContract]
public class FaultBase {
    [DataMember]
    public string ErrorMessage {get;set;}
}

[DataContract]
public class NotFoundFault : FaultBase {
    [DataMember]
    public int EntityId {get;set;}
}

[DataContract]
public class DuplicateItemFault : FaultBase {
    [DataMember]
    public int EntityId {get;set}
}

[DataContract]
public class InvalidStateFault : FaultBase {
}

Затем вы указали бы, что определенные операции могут возвращать такие ошибки:

[OperationContract]
[FaultContract(typeof(NotFoundFault))]
public Entity GetEntityById(int id)

Наконец, вы можете обернуть исключение из DAL таким образом, чтобы WCF вместо этого возвращал конкретную ошибку:

    try {
        return DAL.GetEntity<Entity>(id);
    }
    catch (DAL.NoSuchEntityException ex)
    {
        throw new FaultException<NotFoundFault>(
            new NotFoundFault {EntityId = ex.Id, ErrorMessage = "Can't find entity"});
    }

Я думаю, что разработчик теста пытался заставить вас подумать, что нужно сделать что-то особенное, чтобы сериализовать исключение для удаленного взаимодействия с другим доменом приложения. Это не будет иметь место, если пользовательское исключение было правильно реализовано, так как все поставляемые классы исключений .NET все сериализуемы. Таким образом, возможность сериализации не является оправданием для создания пользовательского исключения, поскольку базовый класс уже должен быть сериализуемым.

Answer 2

Я на самом деле согласен с тем, что 4 неправильный: для обработки общих шагов при создании исключения.

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

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

Answer 3

При использовании служб WCF нам пришлось создавать собственные исключения для сериализации. Так что 3 не может быть правильным ответом.