'undefined is not a function' when promise function not defined

[olore]

Using 1.4.0-beta.5, the following stack trace seems to be the result of an error() function not being defined during promise rejection. The rejection still bubbles up, however the "undefined is not a function" is logged in the console.

http://plnkr.co/edit/JtaNeNEcxFLPH5ByuHI8

TypeError: undefined is not a function
at angular.js:9564
at processQueue (angular.js:14018)
at angular.js:14034
at Scope.$get.Scope.$eval (angular.js:15236)
at Scope.$get.Scope.$digest (angular.js:15051)
at Scope.$get.Scope.$apply (angular.js:15341)
at done (angular.js:9847)
at completeRequest (angular.js:10037)
at XMLHttpRequest.requestLoaded (angular.js:9978)

[jbedard]

That is because the httpError variable is undefined until the assignment takes place (which is after calling .error. That is the same as doing $http(...).error(undefined).

See function hoisting vs var hoisting.

[petebacondarwin]

@jbedard is right. Closing as not a valid issue

[IgorMinar]

The problem is that the error is not nice at all and since it's thrown usually asynchronously with respect to where the callback was registered, it's really hard to debug.

Could we just silently ignore, if the callback is not a function? Would this break Promises A+ spec?

a little bit more context: https://twitter.com/olore/status/577277479506837504

[petebacondarwin]

OK, so this is hard to debug but it is a JS development error not a failure in Angular. Wherever there is code that takes a callback, you have to have defined the callback before you pass it to the code.

Silently ignoring if the callback is not a function will make this even more difficult to debug! There won't even be an error but the error callback will silently not be called if the HTTP request errors.

I think we could throw an error if you call .error() with a thing that is not a function. For example in this case the code is effectively calling .error(undefined), which is not what the error() method expects.

[petebacondarwin]

I created a PR with this in mind. @olore and @IgorMinar is this an acceptable fix?

Now if you fail to pass in a valid function to either error or success you get an instant error.

[stoltene2]

I think this will give more clarity to the situation.

[pkozlowski-opensource]

So, if we want to keep those callbacks close to promises callbacks we should ignore non-function arguments: https://promisesaplus.com/#point-23

[petebacondarwin]

The only reason the promise spec allows us to ignore params is because they are all optional but I am pretty sure that passing no parameters is always an error. In the case of error and success there is only one parameter, so it never makes sense to fail to pass the parameter.

[pkozlowski-opensource]

Well, the spec says "if it is not a function", so I'm not sure it is only about optional params

[olore]

Guys thanks for seeing this one through.
@IgorMinar appreciate you opening this one back up and describing our twitter convo more clearly