No callback execution on read and an error received (exception thrown and not caught)

Oct 10, 2012 at 7:33 AM

In CRM Dynamics I'm executing the following code.

    var temp ={
      urlOrRequest: "https://myurl/2011/OrganizationData.svc/crmk_docusignsettingsSet",
        success: function(dataSet) { alert("Yippi!"); },
        error: function(errorMessage) { alert("Buuuu..."); },
        handler: null,
        httpClient: null,
        metaData: null

However, I get neither of the callbacks to execute. Everything is just ghostly quiet. As I attempt to close or reload the page, though, I get an error message from CRM Dynamics, the partial contents of which are listed below.

      <Message>Exception thrown and not caught</Message>

Given my competence level with CRM Dynamics (low) and with DataJS package (loooow), I'm stuck having no clue as to why it doesn't work nor how to trouble-shoot it. I've checked out all the examples I could find on the page. I understand them but that doesn't help me get my code to work.

Any suggestions would be warmly appreciated.

Oct 16, 2012 at 7:18 PM

Hi Chamster,

  I'm not knowledgeable on CRM Dynamics; however, the call you have to the function is wrong.  The success callbacks, handler, httpclient and metadata are not specified a part of the reuqest object; rather they are direct arguments of the function.  Please look here for the function reference for more details on its usage.


Alex Trigo.

Oct 16, 2012 at 9:29 PM

You're absolutely right. I discovered that a few days ago myself but forgot to update the question here. My apologies for that. Nevertheless, I'm wondering how come the approach I (wrongly) used hasn't been implemented. My impression is that it's the preferred, if not recommended, way to create JavaScript "objects". Am I mistaken? I resolved that by adding my own "constructor" that picks the input, splits it and puts it into the correct parameters. Is there a technical reason that should be avoided?

Oct 24, 2012 at 4:09 PM

Hi Chamster,

   The approach that you mention is only a matter of style... When we originally choose to implement the library we went with the option of specifying the success and error callbacks and additional stuff not describing the request on their own arguments.  Putting everything into an "arguments" object is a nice usage optimization and we will consider it for further revisions of the library.  In the end is only a matter of style and preference.. for example, we could have elected to return a promise from the and OData.request functions instead (which might be an interesting idea :))


Alex Trigo.