Warning: a promise was rejected with a non-error: [object String]

[peteruithoven]

In quite a couple of places promises are rejected with a non-error, a few examples: https://github.com/colinskow/superlogin/blob/master/lib/session.js#L67 https://github.com/colinskow/superlogin/blob/master/lib/session.js#L77 https://github.com/colinskow/superlogin/blob/master/lib/util.js#L40 https://github.com/colinskow/superlogin/blob/master/lib/util.js#L47 https://github.com/colinskow/superlogin/blob/master/lib/local.js#L25

This seems to be one of the causes of getting a very uninformative "unauthorized" response from the server when something is wrong with a given session.

[sandro-pasquali]

Yes, it would be nice to return new Error('something'), for the reasons given here by the author of the bluebird Promises implementation SuperLogin uses: https://github.com/petkaantonov/bluebird/blob/master/docs/docs/warning-explanations.md#warning-a-promise-was-rejected-with-a-non-error

In my case these things end up in error logs, which is problematic for us.

[peteruithoven]

But if you properly catch the errors, why would they end up in logs?

[sandro-pasquali]

There's more to it than that. Regardless, think about catching errors in a Promise chain. They are often caught by type. When errors are predictably proper Error objects, with a type, a .message property, and so forth (and not just in superlogin handlers, but in an entire applications Promise substructure) I think there is a tendency for the code to be easier to comprehend and maintain. It would be unusual for me to think to break that consistency in such a critical area (ie. introduce complexity to the system managing risk so as to satisfy some localized need that is likely less important than overall application stability).

I think it's great that this is about the biggest quibble you can make about superlogin's design. It's amazingly well designed.