Provide an `onError` callback for Forms 2.0 form submission

[John_Wnek]

Currently, the Forms 2.0 JS 'form' object has an attached `onSuccess` callback/handler, but no `onError` handler.  Considering that the form submission is making an asynchronous request, it stands to reason that there should be a callback available to deal with error responses.  Upon further investigation I found that an `onError` callback method actually exists in the Forms 2.0 JS (line #3901 of {{instance}}.marketo.com/js/forms2/js/forms2.js), it just isn't bound to the 'forms' object and thus is not available publicly.

var onError = function (){
  //TODO: What should happen if the form submission fails?
  log(arguments);
  if(priv.submitButton){
    var btn = priv.submitButton.find("button"); 
    btn.removeAttr('disabled');
    btn.html(formData.ButtonText || formData.SubmitLabel || "Submit")
  }
}

My suggestion here is to add `priv.onError = []` in the JS, bind the onError method to the forms object so customers can use it, then modify the onError method to handle callback like this:

var onError = function (values, followup){
  $.each(priv.onError, function (i, errorFn){
    errorFn(values, followup)
  });
};

  I'm curious if there is a specific reason that this error handler isn't available, in general it's considered best practice in Javascript to have both success and error callbacks for deferred requests.

[SanfordWhiteman]

Prob is the upsert to the Marketo db is out-of-band.  So what you might casually think of as "error" -- datatype errors that prevent the entire form from being processed, or field blocking rules that cause selected data to be discarded -- cannot be known to the client.

So while the missing onError might seem weird, if we had the event it but it only caught the most brutal sort of errors (like network errors or server failure on the forms endpoint) that would be misleading, too.

[John_Wnek]

That makes sense that DB updates are out of band, and thus the user should expect successful responses even if there is bad data in the form due to client-specific customization.  Where I take issue is, that's not an excuse to exclude an error handler.  The purpose of an error callback in Javascript is to act as a safety net against any client side errors, regardless of whether they are error responses from the server or something in between.

I disagree that providing an error handler is misleading, it implies that there are no errors to be handled, which is false.  You even say so yourself... `server failure on the forms endpoint`... there is in fact a possibility that there will be error responses from Marketo's server.  This is a valid reason to provide an error handler.  Providing the `onError` event strictly for handling these `brutal sort of errors` and providing an explanation in the documentation that this `onError` event is only implemented for generic error handling is not misleading, it's a standard callback practice in asynchronous Javascript programming.  It is far more misleading to withhold information and make incorrect assumptions about customer implementation than it is to provide a utility method in a public-facing javascript library.

[SanfordWhiteman]

Sure, I wasn't actually objecting to the feature! But if history is a guide -- and it usually is! -- surrounding documentation is more necessary than the feature itself. Almost no one knows that a form post can be entirely discarded, that type coercion can remove fields completely, or that tracking protection can break form operation, and these are happening more in the real world than the endpoint failing. There needs to be deeper documentation outside of my blog and Community posts.

More important: there is a way to trap the errors now.  I'll write it up for you in a couple of days.