володька трынькин,


На мой взгляд лучше все же использовать FaultContract.

1) для всего использовать FaultException. этот вариант мне не очень нравится, поскольку не логично иксепшены пробрасывать, когда у тебя, например, либо входной параметр не из нужного диапазона, либо какое-нибудь обязательное поле входной сущности не заполнено

А почему не логично? Если у вас не заполнено обязательное поле, это вполне себе повод кинуть исключение, тем более что это стандартных механизм сообщить об ошибке.
Я бы создал некий класс OperationFailedException, перехватывал бы все исключения и генерировал бы вышеупомянутое с описанием ошибки (при желании), т.е. примерно так:




Что касается создания кастомного result-класса, то можно добавить поле object Result (поле Description же есть, а при успешной выполнении операции, не требующей результата, оно скорее всего не будет инициализировано). Единственное что нужно, чтобы сериализатор умел получать актуальный тип объекта, а не пытался сериализовать как object. Вы указали, что сервисом будут пользоваться не только .net клиенты, соотв-но, скорее всего данные будут гоняться в каком-нибудь json, а ему все равно из чего будет состоять объект. Про protobuff и прочие не могу сказать.

Или попробовать сделать обобщенным классом OperationResult<T>, но на счет этого я не уверен, т.к. не пробовал.

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

Если у вас не заполнено обязательное поле, вы уже не можете работать дальше, вы не можете должным образом выполнить действие в контексте вашей операции. Это не означает "критический сбой" вроде OutOfMemory, но с точки зрения вашего кода это как раз таки "неожиданная ситуация при которой дальше никак нельзя работать" (в контексте данного запроса). Посмотрите на то, как это реализовано в ASP.NET. Фреймворк может перехватить исключение и транслировать его в соотв. статус-код HTTP, например, если вы выкините что-то вроде UnauthorizedException, можно смапить его на 401 код ошибки.
Еще в качестве плюса - использование FaultContract не переводит канал в состояние Faulted. Вы точно определяете, что выполнение обращения к серверу может завершится неудачей и это нормально. А уже каким образом вы будете данную "неудачу" обрабатывать - кидать исключение повторно, пытаться анализировать и как-то восстановить систему (в вашем примере - предложить ввести требуемое поле) это уже решать клиенту. Но что использовать решать, конечно, вам.

как можно избавиться от дублирования кода в каждом методе. ведь у нас в каждом методе сервиса должен быть обработчик ошибок try-catch и причем с несколькими типами иксепшенов. это кстати будет при любом из двух способов. какие-то wrapper -ы писать?..

Можно попробовать инструментирование кода (PostShart, Afterthrought), можно оставить код, связанный с обработкой ошибок в классе WCF сервиса, а всю логику вынести в другой класс. WCF сервис соотв-но будет делегировать работу этому внутреннему классу.