WCF - бросить исключение или FaultException?

Question

Что эффективнее?Создание исключения или создание ошибки ... Я вижу, что существует 2 сценария:

1. Возникла исключительная ситуация, и вы ее перехватываете, вы бросаете существующую Exception или создаетеновый FaultException и выбросить его?

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

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

Answer 1

Исходя из перспективы контракта WSDL, каждая операция может иметь не более одного ответа.Однако вы можете определить несколько договоров о сбоях, которые в основном говорят клиенту: «Ожидайте ответ, определенный как DataContractX, или ответ о сбое, определенный как FaultContractY или FaultContractZ».

Использование FaultExceptions позволяет вамболее точный контроль над тем, как представлен ваш WSDL (или при написании совместимого сервиса для уже определенного WSDL).

Если вы действительно пытаетесь достичь взаимодействия и полностью используете wsdl и soap для достижения этого, вам потребуетсяиспользовать FaultExceptions.Если вы используете WCF во взаимодействии только с .NET, вы можете использовать исключения или сбои исключений, я не думаю, что разница в производительности будет существенной (общение по сети на порядок более значимо, чем оборачивание исключений во время выполнения WCF в общий тип).Неисправность при передаче по проводу).

Answer 2

Это может зависеть от того, где и как вы хотите обработать исключение. Клиент (независимо от платформы) всегда получит исключение ошибки мыла, независимо от того, допускает ли код службы необработанные исключения, служба явно вызывает FaultException или генерирует общую версию FaultException.

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

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

Answer 3

Насколько я понимаю, если вы используете wsHttpBinding и если вы генерируете исключение .Net, а не FaultException, канал сервер-клиент будет в состоянии сбоя, и объект прокси-класса придется воссоздавать, так как существующий объект прокси будетбыть непригоднымПоэтому рекомендуется использовать FaultException.

Answer 4

Если вы просто сгенерируете исключение, используя «Exception», служба WCF вызовет FaultExceptionin позади, и основная причина исключения никогда не будет известна клиенту, если вы не упомянете <serviceDebug includeExceptionDetailInFaults="true"/> в web.config. Если вы хотите, чтобы клиент знал причину / пользовательское сообщение за исключением, предпочтите FaultException. Лучше всего иметь исключение с затрудненным типом.