Returning error conditions to a Javascript client from a .NET web service method

This is kind of a 2 part question:

1) What is the better approach, letting .NET convert native objects into JSON, or using wrappers and encoding them myself (e.g. public string DataTableToJSON(DataTable))

2) If the answer to the first question is the former approach, how best to pass error conditions to the client (JavaScript AJAX requests, generally with jQuery or in this specific case, Sencha Touch (Ext))? My current method (explained further down in this question) seems to work fairly well, but there is a problem that seems to be client-dependent.

My 'old' way of returning responses from web services was to declare all methods as strings. I've been doing this for a couple years and it works fine, but feels a bit clunky. For example:

public string Test(){
  try{
    Dataset ds = SomeMethodThatReturnsADataSet();
  } catch (Exception ex){
    return "ERROR"; 
    //my JS checks for these messages to be sure everything went OK on the server
  }
  return DataTable_To_JSON(ds); 
  //at the client this looks something like {d:"[[\"Row1Data\"],[\"Row2Data\"]]"}
}

Obviously this creates a slight overhead at the client because we have to have an extra line of JavaScript such as var data = JSON.parse(response.d);

So recently I became aware that given a ResponseFormat = ResponseFormat.Json argument in the web service, .NET would handle JSON encoding some .NET objects (sadly I can't get the DataTable type to work, but that's another question). So now my web service methods look more like this:

[WebMeth开发者_运维问答od]
[ScriptMethod(ResponseFormat = ResponseFormat.Json, XmlSerializeString = false)]
public List<MyObject> GetMyObjectList(string arg){
  List<MyObject> li = MyObjectClass.GetList(arg);
  if(li.Count > 500){
    //Since we must return a .NET List<MyObject> I can't return strings on error conditions, so this isn't an option:
    return "TOO_MANY_RESULTS";
    //I saw an example somewhere to do this which works _almost_ great:
    throw new Exception("TOO_MANY_RESULTS");
  }
  return li;
}

Like I said in the code comments, throwing an exception returns HTTP 500 with a nicely formatted JSON response which is easy to trap and handle in the "failure" callback in Ext.Ajax.request, like so: (using Chrome and Safari)

{"Message":"TOO_MANY_RESULTS","StackTrace":" at ...","ExceptionType":"System.Exception"}

HOWEVER, for some reason when testing the application on the iPad, I get a 'generic' exception message response:

{"Message":"There was an error processing the request","StackTrace":"","ExceptionType":""}

I have debugged and traced the code and it really is hitting the same "throw new Exception" line in C#, it is not failing in some other portion of the code. For some reason, it seems the client's request headers are somehow affecting what .NET is deciding to return.

Does anyone have any ideas of what to try to get .NET to always return the message I am passing into the Exception?

EDIT: Also works correctly on Android (get "TOO_MANY_RESULTS" in server response). Will test iPhone as soon as I get a chance.

EDIT 2: Works correctly on iPhone simulator, physical iPhone is not getting along with our wireless point today, couldn't test actual device.

I can answer the first question. Unless the default WCF handling for JSON does not work for you, I would not incur the overhead of customization. If I were to stray from standard WCF handling on the server side, especially for REST implementations (which are good for your mobile scenario), I would look into the WCF Web API, which is now been moved to the AppFabric team at Microsoft. You can find the latest release bits on CodePlex (still in beta). Stray from the built in stuff only if needed, as there is a lot of coding overhead.

Not sure on question #2, as I have not worked a lot with the mobile side of the equation (I work on the server/API side). I am also not certain if the WCF Web API handles this differently, but would suggest at least looking that direction, especially if you are using RESTful services. My reason for recommending is all the signs point to the Web API being the direction Microsoft is heading for the future of REST.