Throw Error when `resolve` does not find dependency to inject

[frapontillo]

Say I have a factory called Config and there is a state such as:

$stateProvider.state('app', {
  url: '/',
  templateUrl: 'views/main.html',
  controller: 'MainCtrl',
  resolve: {
    config: function(Config) {
      return Config.reloadConfig();
    }
  }
}):

The resolve function of course fails, but no Error is thrown! When the project is minified (which is the only case when you notice something is wrong) finding this error is a pain; I had to go by trial and error through a lot of files to notice this.

[nateabele]

I don't understand. Why does it "of course" fail? Because the code is minified and Config is renamed? Try listening for $stateChangeError, or using the error callback in the result of transitionTo().

[frapontillo]

Yes, because it's minified. If I don't correctly declare dependencies in a controller, an error is thrown so I can understand where the error is and how to fix it. It'd be a mess if things start failing silently.

I think that the resolve function is evaluated somewhere in a try block, but the error isn't properly handled, as the console does not display it as it should.

[nateabele]

The error is propagated through the error callback of the promise returned by transitionTo(). Throwing an error would break the model.

[frapontillo]

Maybe printing a message on the error stream would be considered acceptable? Just my 2 cents.

[laurelnaiad]

When you work with promises in angular, it would behoove you to handle the error callbacks in every case. And in such a callback you can log the error yourself. I for one find it annoying when libraries decide on my behalf that they will print something to the log.

edit: if that's what you meant by 'error stream', but now that I'm rereading I'm not sure if that's what you meant.

[nateabele]

@frapontillo You should be able to achieve that for all promise rejections with $provide.decorator().

[frapontillo]

The error callback is one thing, a dependency error is another one. For example, the $http and $resource services do throw an error when there is a network one (say 404). And they do return a $promise.

@stu-salsbury yep, I meant the console.error stream :)

[laurelnaiad]

Funny -- you mention the exact console error that drives me nuts!

[ratbeard]

I had a typo in one of my Services I was using inside of the resolve block and was bit by this as well. I like @frapontillo's suggestion of adding a console.error in, around here I think:

ui-router/release/angular-ui-router.js

Line 371 in aa03555

invocation.reject(reason);

I would say the api and concepts in this library are quite large and take time to fully grasp. Most developers probably starting like me with just a few states and grow it from there, not really thinking of handling errors until they have to spend an hour tracking down a silent failure. Duplicate tickets seems to indicate this isn't too uncommon.

[timkindberg]

I'd be in favor of a console.error entry for broken resolve.

[nateabele]

The resolve just needs to be checked at initialization time.

[reebalazs]

Hi,

I must admit I don't understand the resolution of the issue. Could you please help me understand the status?

My original problem is that any exceptions in the resolver function are caught silently, and when any such exception happens it causes my code breaking silently. We investigated some misterious hangs which left no sign of error. Now I realize that the silent exceptions are the culprit and this is how I found #508 and #696 that are now marked dupes of this issue, which is why I ask here.

@nateabele, you mention: "The error is propagated through the error callback of the promise returned by transitionTo(). Throwing an error would break the model."

When an exception happens in my code in the resolver function, | want to see it in the console. Also, ... yes, it's broken. It will not work anyway since execution stopped at the point of the exception. There is nothing ui-router can do for me at this point.

Could you please help me understand (or point to docs or code) why throwing an error would necessarily break the model? I think this should not be necessary, and perhaps the code can be improved to avoid an exception all-catch which is in general, a very bad thing.