WCF-исключение или исключение FaultException?

что эффективнее? Исключение или ошибка... как я вижу, есть 2 сценария:

  1. произошло исключение и поймано, вы бросаете это существующее Exception или создать новый FaultException и бросил?

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

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

7
exception fault faultexception wcf

4 ответов

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

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

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

13

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

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

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

8

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

1

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

0