Is this code a reasonable way to handle exception in a WebService

[Tony Johansson]

Hello!

Is this a good approach to handle exception. As you can see I log the
exception to the event log and
then thow a HTTP 500 to the client browser ?

public class Service : System.Web.Services.WebService
{
public Service ()
{
//Uncomment the following line if using designed components
//InitializeComponent();
}

private void HandleWebException(Exception e)
{
EventLog log = new EventLog("Application");
log.Source = "NorthwindServices";
log.WriteEntry(e.Message, EventLogEntryType.Error);
}

[WebMethod]
public decimal HowMuchWillItCost(string productName, int howMany)
{
SqlConnection sqlConn = null;
decimal totalPrice
try
{
ConnectionStringSettings cs =
ConfigurationManager.ConnectionStrings["NorthwindConnectionString"];
string connString = cs.ConnectionString;
sqlConn = new SqlConnection(connString);
SqlCommand sqlCmd = new SqlCommand();
sqlCmd.CommandText = string.Format("Select unitPrice from Products
" +
"where ProductName = '{0}'",
productName);
sqlCmd.Connection = sqlConn;
sqlConn.Open();
decimal price = (decimal)sqlCmd.ExecuteScalar();
totalPrice= price * howMany;
}
catch (Exception e)
{
HandleWebException(e);
throw new Exception();
}
finally
{
if (sqlConn != null)
sqlConn.Close();
}

return totalPrice;
}
}

//Tony

 

[Arne Vajhøj]

Is this a good approach to handle exception. As you can see I log the
exception to the event log and
then thow a HTTP 500 to the client browser ?

public class Service : System.Web.Services.WebService
{
public Service ()
{
//Uncomment the following line if using designed components
//InitializeComponent();
}

private void HandleWebException(Exception e)
{
EventLog log = new EventLog("Application");
log.Source = "NorthwindServices";
log.WriteEntry(e.Message, EventLogEntryType.Error);
}

[WebMethod]
public decimal HowMuchWillItCost(string productName, int howMany)
{
SqlConnection sqlConn = null;
decimal totalPrice
try
{
ConnectionStringSettings cs =
ConfigurationManager.ConnectionStrings["NorthwindConnectionString"];
string connString = cs.ConnectionString;
sqlConn = new SqlConnection(connString);
SqlCommand sqlCmd = new SqlCommand();
sqlCmd.CommandText = string.Format("Select unitPrice from Products
" +
"where ProductName = '{0}'",
productName);
sqlCmd.Connection = sqlConn;
sqlConn.Open();
decimal price = (decimal)sqlCmd.ExecuteScalar();
totalPrice= price * howMany;
}
catch (Exception e)
{
HandleWebException(e);
throw new Exception();
}
finally
{
if (sqlConn != null)
sqlConn.Close();
}

return totalPrice;
}
}

No. At least not unless you have a security requirement
not to reveal any information to the client.

With this code the client will not have any clue
about what happened.

And since web services will be called by apps
not seen in a browser, then the client code should
catch the exception and display something to the
user.

And that something could at least potentially
be more informative if the client new what the
problem was.

Arne

 

[Arne Vajhøj]

Hello!

Is this a good approach to handle exception. As you can see I log the
exception to the event log and
then thow a HTTP 500 to the client browser ?

public class Service : System.Web.Services.WebService
{
public Service ()
{
//Uncomment the following line if using designed components
//InitializeComponent();
}

private void HandleWebException(Exception e)
{
EventLog log = new EventLog("Application");
log.Source = "NorthwindServices";
log.WriteEntry(e.Message, EventLogEntryType.Error);
}

[WebMethod]
public decimal HowMuchWillItCost(string productName, int howMany)
{
SqlConnection sqlConn = null;
decimal totalPrice
try
{
ConnectionStringSettings cs =
ConfigurationManager.ConnectionStrings["NorthwindConnectionString"];
string connString = cs.ConnectionString;
sqlConn = new SqlConnection(connString);
SqlCommand sqlCmd = new SqlCommand();
sqlCmd.CommandText = string.Format("Select unitPrice from Products
" +
"where ProductName = '{0}'",
productName);
sqlCmd.Connection = sqlConn;
sqlConn.Open();
decimal price = (decimal)sqlCmd.ExecuteScalar();
totalPrice= price * howMany;
}
catch (Exception e)
{
HandleWebException(e);
throw new Exception();
}
finally
{
if (sqlConn != null)
sqlConn.Close();
}

return totalPrice;
}
}

And consider replacing closing connection in finally
with the construct:
using() { }

Arne

 

[Tony Johansson]

Hello!

Is this a good approach to handle exception. As you can see I log the
exception to the event log and
then thow a HTTP 500 to the client browser ?

public class Service : System.Web.Services.WebService
{
public Service ()
{
//Uncomment the following line if using designed components
//InitializeComponent();
}

private void HandleWebException(Exception e)
{
EventLog log = new EventLog("Application");
log.Source = "NorthwindServices";
log.WriteEntry(e.Message, EventLogEntryType.Error);
}

[WebMethod]
public decimal HowMuchWillItCost(string productName, int howMany)
{
SqlConnection sqlConn = null;
decimal totalPrice
try
{
ConnectionStringSettings cs =
ConfigurationManager.ConnectionStrings["NorthwindConnectionString"];
string connString = cs.ConnectionString;
sqlConn = new SqlConnection(connString);
SqlCommand sqlCmd = new SqlCommand();
sqlCmd.CommandText = string.Format("Select unitPrice from
Products
" +
"where ProductName = '{0}'",
productName);
sqlCmd.Connection = sqlConn;
sqlConn.Open();
decimal price = (decimal)sqlCmd.ExecuteScalar();
totalPrice= price * howMany;
}
catch (Exception e)
{
HandleWebException(e);
throw new Exception();
}
finally
{
if (sqlConn != null)
sqlConn.Close();
}

return totalPrice;
}
}

And consider replacing closing connection in finally
with the construct:
using() { }

Arne

I know that using is much better then using close but this was just a copy
from a book that I didn't care to rewrite to using

//Tony.

 

[Registered User]

- example code snipped -

No. At least not unless you have a security requirement
not to reveal any information to the client.

Obviously any information regards error information. The absence of an
explicit security requirement should not be taken to mean that
white-box exposure of the service is permissible or desirable.

With this code the client will not have any clue
about what happened.

except that the request failed.

And since web services will be called by apps
not seen in a browser, then the client code should
catch the exception and display something to the
user.
yep

And that something could at least potentially
be more informative if the client new what the
problem was.

The questions are :
1 - how detailed should this information should be
2 - will the information be meaningful to all users
3 - can the information help the user directly resolve the problem.

The answer to the third question is almost always no.

The second question can be answered with the classic "Yes, no, I
dunno... maybe" The answer doesn't have to consider technical
skills and abilities, just the various cultures of the users. An error
message presented in English will convey little meaning to users who
don't understand English.

Based upon those answers, a suitable answer to the 'how detailed'
question is 'not very'.

IMO in most situations using the generic internal server error is the
most practical solution.

regards
A.G.

 

[Arne Vajhøj]

Obviously any information regards error information. The absence of an
explicit security requirement should not be taken to mean that
white-box exposure of the service is permissible or desirable.

Information about the problem does not imply white box. Exceptions
are part of the public API.

How much can be revealed depends on the context.

except that the request failed.

The questions are :
1 - how detailed should this information should be
2 - will the information be meaningful to all users
3 - can the information help the user directly resolve the problem.

The answer to the third question is almost always no.

The second question can be answered with the classic "Yes, no, I
dunno... maybe" The answer doesn't have to consider technical
skills and abilities, just the various cultures of the users. An error
message presented in English will convey little meaning to users who
don't understand English.

Based upon those answers, a suitable answer to the 'how detailed'
question is 'not very'.

Given that web services are not intended to be called
by users but by apps, then human culture should not matter
much.

Potential relevant information includes:
- whether it would be relevant to try again immediately or not
- other suggestions for action to take

IMO in most situations using the generic internal server error is the
most practical solution.

Just like ordinary methods should really not throw Exception, then I
don't think web services should.

Be specific.

Otherwise the client code would have a hard time figuring out what
to do.

Unless policies require that nothing be revealed what so ever. Which
is not very client friendly, but still happens.

Arne

 

[Registered User]

Information about the problem does not imply white box. Exceptions
are part of the public API.

How much can be revealed depends on the context.

Context is important but it's not a matter of what can be revealed but
what should be revealed.Unless the client can use detailed information
to resolve the error, I don't believe that there is any general need
to detail what sort of internal error has occurred.

Given that web services are not intended to be called
by users but by apps, then human culture should not matter
much.

Then why is there any need to detail the cause of the error? The
client app doesn't care about the why or how of failure. All the
client app cares about is the boolean; did it work or not. The culture
part comes into play when it is determined the client needs to inform
the user with textual details of the exception which are provided by
the remote server.
- quote taken from above -- end quote -

Potential relevant information includes:
- whether it would be relevant to try again immediately or not
- other suggestions for action to take

This assumes the service can/should self-diagnose the issue. Let us
say the SQL server was unavailable. That is essentially all the
service can communicate ut the problem. The service can't see into the
future and know the state of the SQL server when the next request is
made. As such the service can provide no answer to the question 'is it
relevant to try again immediately or not?'

Suggesting alternative actions is well outside of the scope of an
agnostic service. Determining what the client should do when an error
occurs is the client's responsibility.

Just like ordinary methods should really not throw Exception, then I
don't think web services should.


Be specific.

Success or failure is pretty specific. More detail could be provided
by returning exception messages or a plethora of hresult-like values
but is such detail really necessary? In some cases yes but those
occasions are most generally when both client and service are
proprietary designs with built-in dependencies.

Otherwise the client code would have a hard time figuring out what
to do.

An agnostic service knows nothing about the client or its
functionality beyond the fact the client has made a request.
Abstractly HTTP 404 and 500 errors are the same; a successful response
from the remote service is unavailable. Although the negative case is
often given short-shrift, the client design must consider what to do
when such failures occurs.

Unless policies require that nothing be revealed what so ever. Which
is not very client friendly, but still happens.

I appreciate your thoughts but I just don't believe providing detailed
error information is client-friendly when the information will not
assist the client in resolving the error.

regards
A.G.

 

[Arne Vajhøj]

Context is important but it's not a matter of what can be revealed but
what should be revealed.Unless the client can use detailed information
to resolve the error, I don't believe that there is any general need
to detail what sort of internal error has occurred.

If there are no security requirement to hide it, then I don't
see any reason not to send it. The server side does not know
whether it could be useful or not.

Then why is there any need to detail the cause of the error?

For the client app. To log and/or act on.

The
client app doesn't care about the why or how of failure. All the
client app cares about is the boolean; did it work or not.

Not necessarily.

The client app could care about:
- informing MIS
- whether it should retry after short time or that is hopeless
- whether the server side is in a consistent state or a big mess

The culture
part comes into play when it is determined the client needs to inform
the user with textual details of the exception which are provided by
the remote server.

I would expect exceptions texts to be in "IT English" not
the local language anyway. They are not intended for
end users.

- quote taken from above -
- end quote -

This assumes the service can/should self-diagnose the issue. Let us
say the SQL server was unavailable. That is essentially all the
service can communicate ut the problem. The service can't see into the
future and know the state of the SQL server when the next request is
made. As such the service can provide no answer to the question 'is it
relevant to try again immediately or not?'

Not true.

Some exceptions like: no available connection in connection pool
and transaction lock timeout are transient in nature while
other like server not available, table does not exist
can be expected to last for some time.

Suggesting alternative actions is well outside of the scope of an
agnostic service. Determining what the client should do when an error
occurs is the client's responsibility.

Exactly.

Which is why the server side should not decide that the
client should not do anything by not providing any info.

Success or failure is pretty specific.

Success is. Failure is not.

More detail could be provided
by returning exception messages or a plethora of hresult-like values
but is such detail really necessary?

I would expect it of a good service.

In some cases yes but those
occasions are most generally when both client and service are
proprietary designs with built-in dependencies.

If the need exists, then a pure exception API can be created
to hide the implementation.

An agnostic service knows nothing about the client or its
functionality beyond the fact the client has made a request.
Abstractly HTTP 404 and 500 errors are the same; a successful response
from the remote service is unavailable. Although the negative case is
often given short-shrift, the client design must consider what to do
when such failures occurs.

Yes. But if they only has the HTTP error then they can't do
anything.

Arne

 

[Arne Vajhøj]

Is this a good approach to handle exception. As you can see I log the
exception to the event log and
then thow a HTTP 500 to the client browser ?

public class Service : System.Web.Services.WebService
{
public Service ()
{
//Uncomment the following line if using designed components
//InitializeComponent();
}

private void HandleWebException(Exception e)
{
EventLog log = new EventLog("Application");
log.Source = "NorthwindServices";
log.WriteEntry(e.Message, EventLogEntryType.Error);
}

[WebMethod]
public decimal HowMuchWillItCost(string productName, int howMany)
{
SqlConnection sqlConn = null;
decimal totalPrice
try
{
ConnectionStringSettings cs =
ConfigurationManager.ConnectionStrings["NorthwindConnectionString"];
string connString = cs.ConnectionString;
sqlConn = new SqlConnection(connString);
SqlCommand sqlCmd = new SqlCommand();
sqlCmd.CommandText = string.Format("Select unitPrice from Products
" +
"where ProductName = '{0}'",
productName);
sqlCmd.Connection = sqlConn;
sqlConn.Open();
decimal price = (decimal)sqlCmd.ExecuteScalar();
totalPrice= price * howMany;
}
catch (Exception e)
{
HandleWebException(e);
throw new Exception();
}
finally
{
if (sqlConn != null)
sqlConn.Close();
}

return totalPrice;
}
}

No. At least not unless you have a security requirement
not to reveal any information to the client.

With this code the client will not have any clue
about what happened.

And since web services will be called by apps
not seen in a browser, then the client code should
catch the exception and display something to the
user.

And that something could at least potentially
be more informative if the client new what the
problem was.

It should be mentioned that the .NET framework
has provided a class System.Web.Services.Protocols.SoapException
to help communicate exceptions to client.

The class supports a bunch of data to be transferred to
the client.

See:

http://msdn.microsoft.com/en-us/library/system.web.services.protocols.soapexception.aspx
for details.

The following article explains a bit about how it can
be used:

http://www.developer.com/net/csharp/article.php/3088231/Exception-Handling-in-Web-Services.htm

[I have not studied the code in the article in detail, so I will
not vouch for its quality]

Arne


Arne

 

[Registered User]

If there are no security requirement to hide it, then I don't
see any reason not to send it. The server side does not know
whether it could be useful or not.

The service's interface is what is public, not the internal
implementation. It's all about scope.

- much snippage -

For the client app. To log and/or act on.

Logging the details of a web service's internal error is not the
responsibility of the client. Once again it is a matter of scope.

Not necessarily.

The client app could care about:
- informing MIS

And again it is a matter of scope. The client can inform the world of
an external error but reporting the specific details of the internal
error is the responsibility of the service.

- whether it should retry after short time or that is hopeless
- whether the server side is in a consistent state or a big mess

These are measures that can't be defined by a single error. A 503
error indicates a server is temporarily unavailable. How long is
temporarily?

I would expect exceptions texts to be in "IT English" not
the local language anyway. They are not intended for
end users.

And what will the client do with this IT English? It might as well be
error codes.

Not true.

Some exceptions like: no available connection in connection pool
and transaction lock timeout are transient in nature while
other like server not available, table does not exist
can be expected to last for some time.

A service request failing at 23:00:30 due to the server being
unavailable says nothing about how long the server will be
unavailable. The server could be down for hours or connectivity could
be restored at 23:00:31.

AFA a table not existing that shouldn't happen in a production
environment.

The major problem is the client assumes the service will always be
implemented the same way. What happens when the service's
implementation changes from running SQL queries against a
transactional database to making MDX queries against a
multidimensional cube? It's the same interface returning the same data
with the only changes being to the implementation and possible
internal errors. If implementation changes are not transparent to the
client, every client will need to be refactored/redesigned to
accomodate such changes. That an extremely poor design.

Changing the service's implementation should never impact service
clients as long as the interface remains unchanged.

Exactly.

Which is why the server side should not decide that the
client should not do anything by not providing any info.


Success is. Failure is not.


I would expect it of a good service.

If the client is dependent upon both the service's interface and
implementation, I wouldn't call either end very good. Deliberately
introducing such dependencies is a questionable practice because it
breaks the dependency injection design pattern provided by the service
and its interface. One tenet of inversion of control is systems should
make no assumptions about what other systems do or should do and how
they do it.

If the need exists, then a pure exception API can be created
to hide the implementation.

Not to hide the implementation details but to describe potential
errors in a generic manner similar to how HTTP status codes are used.
The implementation is hidden by default courtesy of the indirection
provided by the service and its interface.

Yes. But if they only has the HTTP error then they can't do
anything.

This assumes there are specific actions the client can take to
ameliorate specific issues based upon specific errors. Can you point
me to an example service with a client that behaves in such a manner
based upon SQL server errors? The reality is most of the time the only
thing the client can do try again later.

regards
A.G.

 

[Arne Vajhøj]

The service's interface is what is public, not the internal
implementation. It's all about scope.

But exceptions thrown are part of the interface.

And if implemented correctly is not tied to
implementation.

- much snippage -
Logging the details of a web service's internal error is not the
responsibility of the client. Once again it is a matter of scope.

Sure it is the responsibility of the client.

The client should not assume that the server does not.

And again it is a matter of scope. The client can inform the world of
an external error but reporting the specific details of the internal
error is the responsibility of the service.

The client should not assume what the server does.

These are measures that can't be defined by a single error.

Exactly. Which is why more details are needed.

A 503
error indicates a server is temporarily unavailable.

Which is probably one of the reasons it is considered best
practice to use SOAP faults with more details instead
of just HTTP status codes.

And what will the client do with this IT English? It might as well be
error codes.

It is more unambiguous but tend to be more magic numbers.

It is standard to use "text error codes".

A service request failing at 23:00:30 due to the server being
unavailable says nothing about how long the server will be
unavailable. The server could be down for hours or connectivity could
be restored at 23:00:31.

If a service is unavailable at a time where it should be, then
retrying every 100 ms is not a good strategy, because there
is a pretty good chance that it will take minutes maybe hours.

AFA a table not existing that shouldn't happen in a production
environment.

True.

But then the service should not be unavailable in the first place.

The major problem is the client assumes the service will always be
implemented the same way. What happens when the service's
implementation changes from running SQL queries against a
transactional database to making MDX queries against a
multidimensional cube? It's the same interface returning the same data
with the only changes being to the implementation and possible
internal errors. If implementation changes are not transparent to the
client, every client will need to be refactored/redesigned to
accomodate such changes. That an extremely poor design.

Changing the service's implementation should never impact service
clients as long as the interface remains unchanged.

Absolutely true.

But no one suggested throwing SqlException.

Web services are no difference from any other types
of well defined interfaces.

The exceptions thrown externally should be implementation
independent.

BTW, even the original post in this thread was, so no
problem here.

If the client is dependent upon both the service's interface and
implementation, I wouldn't call either end very good.

True, but exception information does not need to be dependent
on implementation.

Catching implementation specific exceptions and throwing API
defined exceptions is very standard.

Deliberately
introducing such dependencies is a questionable practice because it
breaks the dependency injection design pattern provided by the service
and its interface. One tenet of inversion of control is systems should
make no assumptions about what other systems do or should do and how
they do it.

DI/IoC does not seem particular relevant for web services.

This assumes there are specific actions the client can take to
ameliorate specific issues based upon specific errors. Can you point
me to an example service with a client that behaves in such a manner
based upon SQL server errors? The reality is most of the time the only
thing the client can do try again later.

The SOAP standard defines so called server SOAP faults to
communicate this type of information.

And .NET framework both .asmx and WCF has added classes
to support it.

Either somebody is using it or a lot of resources has been wasted.

Arne

 

[Arne Vajhøj]

Is this a good approach to handle exception. As you can see I log the
exception to the event log and
then thow a HTTP 500 to the client browser ?

public class Service : System.Web.Services.WebService
{
public Service ()
{
//Uncomment the following line if using designed components
//InitializeComponent();
}

private void HandleWebException(Exception e)
{
EventLog log = new EventLog("Application");
log.Source = "NorthwindServices";
log.WriteEntry(e.Message, EventLogEntryType.Error);
}

[WebMethod]
public decimal HowMuchWillItCost(string productName, int howMany)
{
SqlConnection sqlConn = null;
decimal totalPrice
try
{
ConnectionStringSettings cs =
ConfigurationManager.ConnectionStrings["NorthwindConnectionString"];
string connString = cs.ConnectionString;
sqlConn = new SqlConnection(connString);
SqlCommand sqlCmd = new SqlCommand();
sqlCmd.CommandText = string.Format("Select unitPrice from Products
" +
"where ProductName = '{0}'",
productName);
sqlCmd.Connection = sqlConn;
sqlConn.Open();
decimal price = (decimal)sqlCmd.ExecuteScalar();
totalPrice= price * howMany;
}
catch (Exception e)
{
HandleWebException(e);
throw new Exception();
}
finally
{
if (sqlConn != null)
sqlConn.Close();
}

return totalPrice;
}
}

No. At least not unless you have a security requirement
not to reveal any information to the client.

With this code the client will not have any clue
about what happened.

And since web services will be called by apps
not seen in a browser, then the client code should
catch the exception and display something to the
user.

And that something could at least potentially
be more informative if the client new what the
problem was.

It should be mentioned that the .NET framework
has provided a class System.Web.Services.Protocols.SoapException
to help communicate exceptions to client.

The class supports a bunch of data to be transferred to
the client.

See:

http://msdn.microsoft.com/en-us/library/system.web.services.protocols.soapexception.aspx

for details.

The following article explains a bit about how it can
be used:

http://www.developer.com/net/csharp/article.php/3088231/Exception-Handling-in-Web-Services.htm


[I have not studied the code in the article in detail, so I will
not vouch for its quality]

That was .asmx.

For WCF read:

http://www.extremeexperts.com/Net/Articles/ExceptionHandlingInWCF.aspx

Arne

 

[Registered User]

Sure it is the responsibility of the client.

Logging details of other systems' internal errors is the
responsibility of the client? Why? What will be done with that
information's detail once logged.

The client should not assume that the server does not.
????


The client should not assume what the server does.

Correct, the client shouldn't assume anything about the service beyond
the published interface.

Exactly. Which is why more details are needed.


Which is probably one of the reasons it is considered best
practice to use SOAP faults with more details instead
of just HTTP status codes.

No matter how the error is passed, there still is no answer to the
question of 'how long is temporarily?'

The OP was questioning the use exceptions in general. You're are the
one who wants to include internal implementation details with the
exception. This is where we disagree.

It is more unambiguous but tend to be more magic numbers.

It is standard to use "text error codes".

How will the server know? Especially if the server's state is what you
call "a big mess".

If a service is unavailable at a time where it should be, then
retrying every 100 ms is not a good strategy, because there
is a pretty good chance that it will take minutes maybe hours.

Who is advocating continuous retries every 100 ms? How will the server
know if it will take minutes or hours to correct the issue? A poorly
behaved client could retry every 10ms regardless.

There is also a chance the service could be restored in seconds or
even milliseconds. Murphy behaves as he wishes.

True.

But then the service should not be unavailable in the first place.

Well then this whole discussion is moot because not only should the
service never be unavailable, the service should never encounter an
error condition. Oh to live in such a perfect world!

Absolutely true.

But no one suggested throwing SqlException.

Correct but you suggested that exceptions need to specifically
describe the internal error. Some examples you gave were
- quote -
no available connection in connection pool ...
transaction lock timeout ...
server not available ...
table does not exist...
- end quote -

Whether the thrown exceptions are SQL types or not is irrelevant to
the discussion. That is just the wrapper to the content you feel
should be available to the client. I don't believe the content should
describe specific implementation details unless requirements
specifically dictate that information should be made available.

The exceptions thrown externally should be implementation
independent.

This is what I don't understand. How can the exception be
implementation independent and yet describe internal implementation
errors in detail such as the ones quoted above? Please remember the
client's next action is to be based upon the specifics of the
implementation error.

- quote -
Otherwise the client code would have a hard time figuring out what to
do.
- end quote -

You're making a most general assumption that the client can follow a
specific path based upon the specific details of an error. I believe
that generally the only thing a client can do is try again later.

BTW, even the original post in this thread was, so no
problem here.



True, but exception information does not need to be dependent
on implementation.

Catching implementation specific exceptions and throwing API
defined exceptions is very standard.

Yes, this was mentioned several posts ago.
- quote -
Success or failure is pretty specific. More detail could be provided
by returning exception messages or a plethora of hresult-like values
but is such detail really necessary? In some cases yes but those
occasions are most generally when both client and service are
proprietary designs with built-in dependencies.
- end quote -

DI/IoC does not seem particular relevant for web services.

The concepts of avoiding undesirable dependencies are relevant. It
doesn't matter if those dependencies are between client and specific
service implementation or a service's published interface and a
specific implementation.

The SOAP standard defines so called server SOAP faults to
communicate this type of information.

And .NET framework both .asmx and WCF has added classes
to support it.

Either somebody is using it or a lot of resources has been wasted.

SOAP exceptions are nothing new and are useful when they are useful. I
first did that a decade ago to describe errors from an n-tier system a
web service fronted. There were twenty-odd custom faults but none
provided detailed information about specific implementation errors.

It's not about using these tools but how they are used. If using
custom SOAP faults provides no benefit to the client, what is the
point of using custom SOAP faults?

The discussion has devolved to discussing different ways to pass error
information. That makes it a good time to end this discussion. We have
been speaking in abstract generalities which contributes to our
disagreement. Using SOAP faults to describe internal implementation
errors in detail can be done but that does not mean it should always
be done. One size fits all really fits no one very well. In all
likelihood if we were discussing a more specific scenario with known
details we would be in closer agreement.

regards
A.G.