«

I would like to distinguish between two classes of exceptions thrown from my
web service - one that is a standard exception that is not propogated to the
UI and indicates a problem, and one that contains an error message (such as
a validation failure) intended for the user.

Problem is, any exception thrown from this web service ends up wrapped
within a SOAP exception and has its message mashed up with other
information, including the stack trace.

Now I suppose I can find a way around this problem, but I get the impression
that the web service model is simply not designed for this particular mode
of use. Should I give up trying to pass user-destined exceptions from the
web service?

Paul

Usually your WebService methods return objects that have error information
embedded in it. So SOAP/hard exception and application exceptions are
different.

Example in C#

class clsResponse
{
public bool bSuccess = true;
public string sErrMessage = "";
}

class clsRateQuoteResponse : clsResponse
{
public decimal dAmount;
}

[WebMethod]
public clsRateQuoteResponse GetRates(clsRateQuoteRequest rq)
{
try
{
...blablabla....
clsRateQuoteResponse rs = new clsRateQuoteResponse();
if( invalid zip code )
{
rs.bSuccess = falsel;
rs.sErrMessage = "Incorrect zip code";
return rs;
}
...balablabla....
rs.dAmount = $1000M;
rs.bSuccess = true;
return rs;
}
catch(Exception e)
{
....Log exception.......and throw SOAP exception
throw new Excpetion("Sorry, we have an internall error. Please try
again later");
}
}

So if it's a soft error (the one that can be fixed on receiving end like
fixing address for example) you end up with normal response,

For hard errors (like database just died) I prefer to log them/page admin
and respond with SOAP exception.


George.

"PJ6" <> wrote in message
news:%...
>I would like to distinguish between two classes of exceptions thrown from
>my web service - one that is a standard exception that is not propogated to
>the UI and indicates a problem, and one that contains an error message
>(such as a validation failure) intended for the user.
>
> Problem is, any exception thrown from this web service ends up wrapped
> within a SOAP exception and has its message mashed up with other
> information, including the stack trace.
>
> Now I suppose I can find a way around this problem, but I get the
> impression that the web service model is simply not designed for this
> particular mode of use. Should I give up trying to pass user-destined
> exceptions from the web service?
>
> Paul
>

Ahh... yes that is a better way to do it.

Thanks,
Paul

"George Ter-Saakov" <gt-> wrote in message
news:...
> Usually your WebService methods return objects that have error information
> embedded in it. So SOAP/hard exception and application exceptions are
> different.
>
> Example in C#
>
> class clsResponse
> {
> public bool bSuccess = true;
> public string sErrMessage = "";
> }
>
> class clsRateQuoteResponse : clsResponse
> {
> public decimal dAmount;
> }
>
> [WebMethod]
> public clsRateQuoteResponse GetRates(clsRateQuoteRequest rq)
> {
> try
> {
> ...blablabla....
> clsRateQuoteResponse rs = new clsRateQuoteResponse();
> if( invalid zip code )
> {
> rs.bSuccess = falsel;
> rs.sErrMessage = "Incorrect zip code";
> return rs;
> }
> ...balablabla....
> rs.dAmount = $1000M;
> rs.bSuccess = true;
> return rs;
> }
> catch(Exception e)
> {
> ....Log exception.......and throw SOAP exception
> throw new Excpetion("Sorry, we have an internall error. Please try
> again later");
> }
> }
>
> So if it's a soft error (the one that can be fixed on receiving end like
> fixing address for example) you end up with normal response,
>
> For hard errors (like database just died) I prefer to log them/page admin
> and respond with SOAP exception.
>
>
> George.
>
> "PJ6" <> wrote in message
> news:%...
>>I would like to distinguish between two classes of exceptions thrown from
>>my web service - one that is a standard exception that is not propogated
>>to the UI and indicates a problem, and one that contains an error message
>>(such as a validation failure) intended for the user.
>>
>> Problem is, any exception thrown from this web service ends up wrapped
>> within a SOAP exception and has its message mashed up with other
>> information, including the stack trace.
>>
>> Now I suppose I can find a way around this problem, but I get the
>> impression that the web service model is simply not designed for this
>> particular mode of use. Should I give up trying to pass user-destined
>> exceptions from the web service?
>>
>> Paul
>>
>
>