title: Handling simple value rejects in a promise library
body: <p>When the <a href="https://github.com/petkaantonov/bluebird" rel="nofollow">Bluebird</a> module detects a non-<code>Error</code> reject, it reports <code>Warning: a promise was rejected with a non-error</code>.</p>
  
  <p>So when we are writing a reusable promise library, how should we handle the situation when it is the client's code that throws simple values?</p>
  
  <p>Simple <code>my-library</code> example:</p>
  
  <pre><code>var Promise = require('bluebird');
  
  module.exports = function (cb) {
      return new Promise(function (resolve, reject) {
          try {
              cb();
              resolve('some data');
          } catch (e) {
  
              // should we do this?
              reject(e);
  
              // or should we do this?
              // reject(e instanceof Error ? e : new Error(e));
          }
      });
  };
  </code></pre>
  
  <p>A client that consumes it:</p>
  
  <pre><code>var lib = require('my-library');
  
  lib(function () {
      throw 'Regular text';
  })
      .catch(function (error) {
          // - should we expect exactly 'Regular text' here?
          // - or should it be wrapped into Error by the promise library?
      });
  </code></pre>
  
  <p>In the example above we are going to see the same <code>Warning: a promise was rejected with a non-error</code> again, which in this case is obviously the client's fault, but the problem is - it will be reported against the promise library that did the reject.</p>
  
  <p>This brings a question of how a reusable library should handle such cases.</p>
  
  <ul>
  <li><p><strong>Option 1:</strong> do nothing (just use <code>reject(e)</code>), let the client see the warning message <code>Warning: a promise was rejected with a non-error</code>.</p></li>
  <li><p><strong>Option 2:</strong> verify if the error thrown is an instance of <code>Error</code> and if not - do <code>reject(new Error(e))</code>. This enables the client to throw and reject with simple values, which is probably bad.</p></li>
  </ul>
  
  <p>I am looking for a general recommendation here.</p>
  
  <p>Also consider that sometimes the client can be an old library that you are trying to wrap into promises.</p>