Home » ASP.NET » WebServices – Error Handling

WebServices – Error Handling

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 post in ASP.NET

Related Post

  • ASP.NET Application_Error Detecting 404’sASP.NET Application_Error Detecting 404’s For many of you, this is going to be a "Duh!" kind of post.  But while working on this today, I found so many people asking this question and so many others giving the wrong answer, I'm […]
  • ASP.NET JSON  and ViewStateASP.NET JSON and ViewState I received the following question recently about my article "ASP.NET AJAX using JSON - Here’s how." If we update the value of a textbox or label via a JSON web service call - will the […]
  • Validating A WebForms Checkbox . . .Validating A WebForms Checkbox . . . . . . and other ASP.NET controls that the Validation controls can not be wired to.The presentation today may be something you already know how to do.  But, this question comes up […]
  • ASP.NET Response.Redirect() and JavaScriptASP.NET Response.Redirect() and JavaScript Yesterday we covered issues surrounding using ASP.NET's Response.Redirect in server side code. We noted that not handing it correctly could prevent code from running on the server that we […]
  • ASP.NET AJAX using JSON – Here’s how.ASP.NET AJAX using JSON – Here’s how. Last week I wrote a post about how simple JSON is. In it I explained the main differences between using JSON and using the update panel. I really started out thinking I'd get to how to […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer focusing on ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS.Does your team need additional help in any of the above? Contact Dave today.

2 Pingbacks/Trackbacks