Ontem durante um workshop que coordenei sobre SOA num cliente, voltou-se a abordar a questão das excepções...

-Qual a melhor prática para garantir a correcta propagação ou não de excepções para fora dos serviços?

-Que tipo de patterns podem ser aplicados para garantir que excepções mais comprometedoras não possam ser propagadas para consumidores ?

- Como estabelecer a verdadeira diferença entre faltas e excepções ?

Estás provocador, hem? :-)

Efectivamente também já me tinha deparado com essa questão. No geral, é preciso dar ao cliente alguma informação sobre a natureza do erro ocorrido, mas não ao ponto de ele perceber como os serviços estão implementados.

No guia dos Microsoft Patterns&Practices, "Web Service Security: Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0" que saiu há pouco há um pattern que tem tudo a ver com este problema:

Exception Shielding:

Context
A client is accessing a Web service. The Web service is designed according to the principals of service orientation, which ensures that the boundaries of the service are explicit, and requires that exception information related to the internal implementation of the service is managed within the service.

Problem
How do you prevent a Web service from disclosing information about the internal implementation of the service when an exception occurs?

[...]

Solution
Use the Exception Shielding pattern to sanitize unsafe exceptions by replacing them with exceptions that are safe by design. Return only those exceptions to the client that have been sanitized or exceptions that are safe by design. Exceptions that are safe by design do not contain sensitive information in the exception message, and they do not contain a detailed stack trace, either of which might reveal sensitive information about the Web service's inner workings.

(end quote)

Uma potencialidade que acho interessante é que esta "sanitização" de excepções seja configurável, para que possa ser desligada durante processos de desenvolvimento/debug. Curiosamente, o EDRA (v1.1)/Shadowfax tinha isto mesmo:

Configure exception shielding. Added a configurable mode so that exception shielding can be enabled or disabled. Exception shielding is a helpful feature for production environments where an exception should not provide the client with internal information (such as a connection string). During development and testing however, it is useful to see the exceptions that are raised.

Hope this helps.

Já agora, o Exception Handling Block (na Enterprise Library) trata exactamente dessa problemática.

Voltando às questões do Hugo, eu tenho colocada várias vezes a última - qual é diferança entre uma excepção e uma falta. Ainda não encontrei uma resposta. :)

Aliás um dos problemas que tenho sentido com o WCF é anterior à questão do shielding e tem a ver com isso. Como é que faço para, em debug-time, fazer chegar ao cliente (UI) toda a excepção SQL que ocorreu na camada de dados do serviço?

Acho estranho ter que criar uma instância de uma coisa chamada FaultException. Onde, ainda por cima, não percebi ainda como/onde posso meter a excepção original.

Vocês já encontraram um padrão para implementar isto de uma forma "bonita"?

Olá Hugo,

Em relação à questão de WCF, tens uma propriedade no behaviour que te pode tratar disso, e chama-se mesmo returnUnknownExceptionsAsFaults. :)

Em relação às excepções/faltas, a minha questão é mesmo como decidir se uma determinada situação é considerada uma falta ou uma excepção, na altura do desenho....

Por exemplo:

- Um contrato de crédito só pode ser encerrado depois de liquidado. Se tentarem encerrar o contrato de crédito antes de o liquidar, é uma falta ou uma excepção ? (Podemos partir do princípio que não é "nada normal", alguém tentar fazer o contrário ao utilizar normalmente o sistema)

Mais... :)
As excepções/faltas, devem ou não ser globalizadas? (ui.. esta vai gerar confusão!). E se o meu serviço é globalizado ? E se os dados são globalizados ? 

Conceptualmente, qual é mesmo a diferença entre uma falta e uma excepção?

Na minha opinião são exactamente a mesma coisa e a questão só se coloca pelo facto do SOAP introduzir esse conceito das faults. Daí que eu ache que o WCF devia mapear automaticamente, e por defeito, todas as excepções em faults para enviar ao cliente (depois colocava-se a questão do exception shielding).

A opção que referes ("returnUnknownExceptionsAsFaults") é útil mas não resolve o meu problema.
Porque eu quero é retornar as excepções conhecidas. :)
Ou seja, quero tratar a excepção no serviço, fazer algo e depois enviar a mesma excepção ao cliente. O que devia existir era um constructor da classe FaultException que aceitasse como parâmetro uma Exception.

No teu exemplo (do contrato) estamos a falar de um "erro previsto". Logo, na minha lógica, de uma excepção com um determinado tipo pré-definido.

PS: Essa da globalização, nem vale irmos por aí. Talvez no WCF 2.0 tenhamos uma resposta concreta. Caso contrário ainda vamos colocar o cultura do cliente como parâmetro nas operações do serviço.

hgr:

Conceptualmente, qual é mesmo a diferença entre uma falta e uma excepção?

Para mim, (apenas a minha interpretação), falta é uma situação recuperável pelo cliente, e que pode ou deve ser facilmente corrigida pela utilização correcta do serviço. No caso em que dei, optaria por uma falta.

Excepção é mesmo algo que é literalmente isso: uma situação excepcional e não prevista, ao qual o cliente é alheio.

O problema, é que acho que este meu critério não será muito "completo" e correcto.

hgr:

Na minha opinião são exactamente a mesma coisa e a questão só se coloca pelo facto do SOAP introduzir esse conceito das faults. Daí que eu ache que o WCF devia mapear automaticamente, e por defeito, todas as excepções em faults para enviar ao cliente (depois colocava-se a questão do exception shielding).

A opção que referes ("returnUnknownExceptionsAsFaults") é útil mas não resolve o meu problema.
Porque eu quero é retornar as excepções conhecidas. :)
Ou seja, quero tratar a excepção no serviço, fazer algo e depois enviar a mesma excepção ao cliente. O que devia existir era um constructor da classe FaultException que aceitasse como parâmetro uma Exception.

Não te sei dizer como, mas sei que existe forma de fazer +- o que queres, usando o FaultContract. Temos que pensar na serializacao da mensagem, e vamos ter que pensar numa forma de dar a informacao ao consumidor de forma a que ele a possa perceber. O faultcontract normaliza-te esse formato.

hgr:

PS: Essa da globalização, nem vale irmos por aí. Talvez no WCF 2.0 tenhamos uma resposta concreta. Caso contrário ainda vamos colocar o cultura do cliente como parâmetro nas operações do serviço.

:)

Então e se tiveres um Bus ou Broker que possa ser usado simultaneamente por consumidores de culturas diferentes (o meu caso).

Posso te dizer que actualmente, não usamos "parametros" nas operacoes do serviço, mas temos o conceito de consumidores conhecidos, e no segmento de serviços, usamos WS-Addressing para identificar os consumidores, e comportarmo-nos de acordo com a cultura deles.... :) . Durante todo o tempo de vida de invocação do serviço, eu posso saber qual é a cultura do meu consumidor, e comportar-me como ele precisa. O problema começa nas faltas/excepções.. e é mesmo um caso em que temos algumas dúvidas de como nos devemos comportar...