pasring SOAP exceptions

  • Thread starter Thread starter PJ6
  • Start date Start date
P

PJ6

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.
 
Ahh... yes that is a better way to do it.

Thanks,
Paul

George Ter-Saakov said:
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 said:
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
Click to expand...
Click to expand...
 
Back
Top