Best practise of throwing errors and defining error contract

[Baheri]

Can some some guide me to a good link on how to throw errors in a webservice?
Also if there is a standard way of defining different degress of erros while
exposing your webservice to thrid parties?

e.g. Service is busy is category 3 error,
Credit Card Validation failed is a category 1 error,
Retry after some time category 2 error etc

or are these error just returned as a saop fault? without any categories?

[John Saunders]

"Baheri" <Ba****@discussions.microsoft.comwrote in message
news:1A**********************************@microsof t.com...

Can some some guide me to a good link on how to throw errors in a
webservice?
Also if there is a standard way of defining different degress of erros
while
exposing your webservice to thrid parties?

e.g. Service is busy is category 3 error,
Credit Card Validation failed is a category 1 error,
Retry after some time category 2 error etc

or are these error just returned as a saop fault? without any categories?

Soap faults are the standard way to return errors from a web service. You
can define whatever data you want to return in the detail element of the
SOAP fault, and your clients can interpret that in any way they like.

I question whether the server should be telling the client how severe the
error is; the server should be telling the client _what_ the error is,
whether it's caused by the client or the server, and should perhaps give
some indication of how likely it is that the error will recur if the client
tries again without changing what it sends.

John

[Scott Seely]

If you are looking for how to use faults in ASMX, try this article I wrote a
few years ago.

http://msdn.microsoft.com/library/de...ce09172002.asp
"John Saunders" wrote:

"Baheri" <Ba****@discussions.microsoft.comwrote in message
news:1A**********************************@microsof t.com...

Can some some guide me to a good link on how to throw errors in a
webservice?
Also if there is a standard way of defining different degress of erros
while
exposing your webservice to thrid parties?

e.g. Service is busy is category 3 error,
Credit Card Validation failed is a category 1 error,
Retry after some time category 2 error etc

or are these error just returned as a saop fault? without any categories?

Soap faults are the standard way to return errors from a web service. You
can define whatever data you want to return in the detail element of the
SOAP fault, and your clients can interpret that in any way they like.

I question whether the server should be telling the client how severe the
error is; the server should be telling the client _what_ the error is,
whether it's caused by the client or the server, and should perhaps give
some indication of how likely it is that the error will recur if the client
tries again without changing what it sends.

John

[Baheri]

Hi Scott,

Thanks the link was useful. Do you know of any link that lists or describes
the Typical webservice errors that are not in the control of your application
e.g. Service is Busy, Service unavailable etc?

Regards,
Pancham

"Scott Seely" wrote:

If you are looking for how to use faults in ASMX, try this article I wrote a
few years ago.

http://msdn.microsoft.com/library/de...ce09172002.asp
"John Saunders" wrote:

"Baheri" <Ba****@discussions.microsoft.comwrote in message
news:1A**********************************@microsof t.com...

Can some some guide me to a good link on how to throw errors in a
webservice?
Also if there is a standard way of defining different degress of erros
while
exposing your webservice to thrid parties?
>
e.g. Service is busy is category 3 error,
Credit Card Validation failed is a category 1 error,
Retry after some time category 2 error etc
>
or are these error just returned as a saop fault? without any categories?

Soap faults are the standard way to return errors from a web service. You
can define whatever data you want to return in the detail element of the
SOAP fault, and your clients can interpret that in any way they like.

I question whether the server should be telling the client how severe the
error is; the server should be telling the client _what_ the error is,
whether it's caused by the client or the server, and should perhaps give
some indication of how likely it is that the error will recur if the client
tries again without changing what it sends.

John