views:

311

answers:

3

[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);
        }

    });
A: 

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)

Mauricio Scheffer
A: 

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); } });

Xs10tial
A: 

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.

marsbard