Ответ 1
В WCF вы не должны бросать стандартные исключения .NET - это противоречит потенциально совместимой природе WCF. В конце концов, ваш клиент может быть Java или PHP-клиентом, который не имеет понятия об исключениях .NET.
Вместо этого вам нужно выкинуть FaultExceptions (что является стандартным поведением для WCF).
Если вы хотите передать больше информации о том, что пошло не так, посмотрите на общие типы FaultException<T>
:
СЕРВЕР:
public bool Read()
{
if (IsUserValid() == false)
{
throw new FaultException<InvalidUserFault>("User invalid");
}
}
Или, альтернативно (как предложено @MortenNorgaard):
public bool Read()
{
if (!IsUserValid())
{
InvalidUserFault fault = new InvalidUserFault();
FaultReason faultReason = new FaultReason("Invalid user");
throw new FaultException<InvalidUserFault>(fault, faultReason);
}
}
КЛИЕНТ:
try
{
_client.Read();
}
catch (FaultException<InvalidUserFault> e)
{
MessageBox.Show(e.Message);
return;
}
Вы должны объявить свои InvalidUserFault
как контракты данных WCF и определить, какие члены могут вернуться с этим типом (например, код ошибки, сообщение об ошибке и т.д.).
[DataContract]
[Serializable()]
public class BusinessFault
{
... add your fault members here
}
И тогда вы должны украсить свои методы обслуживания возможными ошибками, которые он может бросить:
[FaultContract(typeof(InvalidUserFault)]
[OperationContract]
public bool Read()
.....
Конечно, "quick'n'dirty" взлома - это просто определить, что сервер возвращает детали исключения в своих исключениях FaultExceptions:
<serviceBehaviors>
<behavior name="EmployeeManager_Behavior">
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
</serviceBehaviors>
а затем вы можете проверить исключение FaultException .Detail
для фактического исключения, которое произошло на сервере, но опять же: это скорее взлом, зависящий только от времени разработки, а не от реального решения.
Марк