CODEWITHSUNDEEP
c#asp.netjqueryweb-services
CleverPatrick
CleverPatrick

Reputation: 9483

Getting Better Error Message From ASP.Net [WebMethod] Called From JQuery

[NOTE:I am really looking for some good debugging techniques here. Perhaps some tricks or ways to simplify things of which I am unaware.]

I am using the technique of calling [WebMethods] defined in an ASPX page from JQuery as mentioned here and here. It seems to be an increasingly common method.

I've been using it for a while and, in general, it works great. But while developing it is pretty fragile. Any incorrect parameter will result in a really vague, non-specific, error message. For instance, if I have a fairly complex web method defined as:

[WebMethod]
public static string SaveComplexRecord(int recID, GeneralData general, SomeObject data, SomeOtherObject moreData)
{
   //do a bunch of stuff with that data
}

And GeneralData, SomeObject, and SomeOtherObject all have a mix of various types of parameters (strings, ints, bools, datetimes.) It is very likely, especially during initial development, that I will build the JSON on the client side incorrectly. Perhaps I will do this:

var data = {
    recID: curID,
    general:
    {
        a: aValue,
        b: bValue,
        c: cValue
    },
    data:
    {
        d: dValue,
        e: eValue,
        f: fValue
    },
    moredata:
    {
        g: gValue,
        h: hValue,
        i: iValue
    }
};

Which will result in an error because the name of the third parameter is moreData, not moredata. And that's just an example, there could be any of a hundred other subtle typo-style errors.

If I were calling this method from C# the compiler would give me an error message something like "No overloaded method of SaveComplexRecord takes three parameters." or some other helpful message that points you in the right direction.

So... is there a way of getting ASP.Net to produce better error messages here?

Or is there some utility that will automatically build the JSON parameter structure of a [WebMethod] call? (just like you can automatically get the WSDL of a web service)

...or any other technique that I may be missing?

And for completeness here is how I call these WebMethods from JQuery:

   var jsondata = $.toJSON(data);

    $.ajax({
        type: "POST",
        url: "MyWebPage.aspx/SaveComplexRecord",
        data: jsondata,
        contentType: "application/json; charset=utf-8",
        dataType: "json",
        beforeSend: function(xhr)
        {
            xhr.setRequestHeader("Content-type",
                         "application/json; charset=utf-8");
        },
        success: function(msg)
        {
            //do something on success
        },
        error: function(XMLHttpRequest, textStatus, errorThrown)
        {
            alert("ERROR status:" + textStatus + " error:" + errorThrown);
        }

    });

Upvotes: 4

Views: 2536

Answers (4)

Chris Fewtrell
Chris Fewtrell

Reputation: 7715

Or is there some utility that will automatically build the JSON parameter structure of a [WebMethod] call? (just like you can automatically get the WSDL of a web service)

Yes! The ASP.Net AJAX framework can do this! You could get the framework to generate client side proxy classes for GeneralData, SomeObject and SomeOtherObject classes using the 'GenerateScriptType' attribute on a web service class.
See understanding asp net ajax web servcies for a very good article about the subject.

[Unfortunately, AFAIAA, the GenerateScriptType has no effect when applied to the Page class where your page method is defined - so you will have to add an .asmx purely to get the proxy generation.]

You could perhaps use these classes to build up the data structure that you then JSON stringify when you call .ajax? [One of (the very few) things I really like about the MS AJAX framework is the client side proxy generation: it really does make calling web services and page methods very easy. Having said that, I too am moving towards using jQuery in preference to MS AJAX.]

Or alternatively... Your problem is really that the de-serialisation of the JSON data into the arguments of your page method is done transparently by the framework (which in most cases is a good thing) but when it goes wrong, the feedback you get is less-than-helpful. If you want to trap de-serialisation problems then I think you have to take control of the serialisation either by using custom JSON converters (see here) or by using the rather inelegant sledgehammer approach of having your method accept a string and de serializing the JSN yourself in the method - which is trivial with anyone of the numerous JSON libs out there.

Upvotes: 1

marsbard
marsbard

Reputation: 2178

What I do when returning JSON from a web service is have an object called "ret" containing an attribute "err" as well as the attribute "data" containing the result of the service call. Inside the web service I trap any exceptions and put the exception message on the "err" attribute. Then in the client I check for the "err" attribute being non empty, if it is I know that an error occurred.

Upvotes: 0

Xs10tial
Xs10tial

Reputation: 143

From a jQuery standpoint, your problem is in the error function declaration. Only take one input parameter, and that will have all properties of the error, then you can debug more easily.

If the problem is server side, catch the error there, and create return json containing the error message.

Oh, and if you DO want to check your javascript at compile time, I recommend the add-in from jslint.com.

So:

$.ajax({ type: "POST", url: "MyWebPage.aspx/SaveComplexRecord", data: jsondata, contentType: "application/json; charset=utf-8", dataType: "json", beforeSend: function(xhr) { xhr.setRequestHeader("Content-type", "application/json; charset=utf-8"); }, success: function(msg) { //do something on success }, error: function(err) { alert(e.message); } });

Upvotes: 0

Mauricio Scheffer
Mauricio Scheffer

Reputation: 99730

Javascript is dynamically typed so you can't get a compile-time error. But you could use the old window.onerror + ajax trick (or send the error via ajax in the error callback of jQuery.ajax()), and once you're in the server you can treat it just like any other runtime error (throw an exception, log the error, whatever)

Upvotes: 0

Related Questions