WebServices – Error Handling

June 2009
S	M	T	W	T	F	S
« May		Jul »
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30

June 11th, 2009 |

Author: Dave

tp_vol2_004 Several weeks ago I presented jQuery at the DotNet User’s Group in Connecticut. As part of that presentation, I mentioned that I handle errors from my WebServices in a slightly different way than what most authors teach.

I thought this morning would be a good time to cover that method in detail.

As I mentioned in the presentation, I do not make use of the SoapException stuff that is part of the SOAP standard for WebServices. This is because rolling my own SOAP Exception is a lot of work for not a whole lot of pay back and it doesn’t give me the information I’m really looking for when an exception occurs on the server side. I also don’t let .NET wrap the exception for me because by the time the error gets back to the client, it has even less information than if I had rolled my own.

This is not to say that you shouldn’t handle the SOAP Exception on the client side. There are several reasons why a SOAP Exception might be thrown that have nothing to do with what happened inside the method, but once I’ve successfully made a call into my method, I’m going to handle the exceptions that happen inside the method with my own exception handlers and reporting.

All I do is simply create a structure that has two elements in it. The data I want to return from the web service and a variable I name “err” that is a string that holds the error message from the exception that was thrown. So if my web service returned an Integer, my structure would look something like this:

public struct RetValue
{
    public int value;
    public string err;
}

and then I would use it in my code like this

[WebMethod]
public RetValue Add(int a, int b)
{
    RetValue r;
    try
    {
        r.value =  a + b;
    }
    catch (Exception e)
    {
        r.err = e.Message;
    }
    return r;
}

Obviously, for a real production system, you’d do more with the error handling. This is just a demo.

You might also consider adding the callstack to the structure and returning that so that you can tell where the error came from. You might do that only in debug mode and leave the err for release mode.

I’ve been using this method for years. It might not be the “sanctioned” way of handling errors, but I think it is a lot easier to deal with.

Other Related Items:

Maxxis Larsen TT Mountain Bike TireThe Maxxis Larsen TT is a proven XC winner and a favorite of pro dual slalom racers. Its closely-spaced, small-block tread pattern hooks up in hard co... Read More >

Iron Python in Action

In 2005, Microsoft quietly announced an initiative to bring dynamic languages to the .NET platform. The starting point for this project was a .NET ... Read More >

PLANET EARTH V.1: E-XCEPTION

If you're new here, you may want to subscribe to the mailing list to get notifications of new post and a virtual tour of past topics. Thanks for visiting!

Bookmark to: