Mock $httpBackend.flush() method never return/exit if custom $exceptionHandler use $http

[fantarama]

If a module customize $exceptionHandler like this:

angular.module("myModule", [])
    .factory("$exceptionHandler", ["$http", function ($http) {
        return function (exception, cause) {
            $http.post("myserver/logger/service", exception);
        };
    }]);

With a generic controller's unit test like this:

it('Should call my service', inject(function($httpBackend, $controller) {
    $httpBackend.expectGET('myserver/resources/myresource');
    var ctrl = $controller('mycontroller');

    $httpBackend.flush();

    // ISSUE: code never called if $exceptionHandler POST isn't mocked

    expect(ctrl.someProperty).toBe('somevalue');

}));

The test excecution enter the flush method and never exit causing the browser to halt on a javascript function and Karma stop responding (I need to kill the process!)

If I mock the $http.post("myserver/logger/service", exception) then work as expected.

The main problem is that the code halt on flush method without any visible exception or error, and since logger and exception handling are aspect not focused on controller testing to find out the fail reason is very hard.

[hege91]

Recently I met the very same problem!

For me the error happened when the $httpBackend throws a synchronous error. For example, when the xhr.open call throws (because of a malformed url, or adblock intercepting the call on firefox), the generated exception cannot be caught and will propagate to the $exceptionHandler.
If the $exceptionHandler issues another $http call which will also cause the $httpBackend to fail while flushing, then it will cycle forever.

So, I think your example hangs because the $httpBackend throws a synchronous error, and the $exceptionHandler then tries to start a new $http request, causing a cycle.

I think the main problem is that, it cannot be caught if the $httpBackend throws, and will propagate to the $exceptionHandler every time. Wrapping the $http call in try-catch has no effect, because the flush gets called later. Maybe the $httpBackend should catch the errors itself and trigger some kind of rejection instead.

P.S.: I did some ugly workaround, to prevent the hang:

  $provide.decorator("$httpBackend", function($delegate, $timeout) {
    return httpBackendDecorator;
    function httpBackendDecorator(method, url, post, callback, headers, timeout, withCredentials, responseType) {
      try {
        return $delegate(method, url, post, callback, headers, timeout, withCredentials, responseType);
      } catch (e) {
        $timeout(handleError);
      }
      function handleError() {
        // Here, duplicate the completeRequest function found in the core code of the $httpBackend
        callback(-1, null, null, '');
        // should I call the following?
        // $browser.$$completeOutstandingRequest(noop);
      }
    }
  });