0

I'm using promises for async requests, and I'm wondering what's the best way to reject errors relating to invalid arguments (aka errors which can be detected immediately). I currently simply throw an error like what I normally do in a synchronous function, but wondering if this is bad practice and should I use the reject method of the promise instead?

http://jsfiddle.net/7xv8f600/

function doSomething(time) {
    //option 1
    if (typeof time !== 'number' || time <= 0) throw new Error('invalid argument');

    var deferred = Q.defer();

    setTimeout(function() {
        deferred.resolve('yay');
    }, time);
    return deferred.promise;
};

doSomething('kappa').then(function(data) {
    console.log(data);
});

function doSomething2(time) {
    var deferred = Q.defer();

    //option 2
    if (typeof time !== 'number' || time <= 0) {
        deferred.reject(new Error('invalid argument'));
    } else {   
        setTimeout(function() {
            deferred.resolve('yay');
        }, time);
    }
    return deferred.promise;
};

doSomething2('kappa').then(function(data) {
    console.log(data);
}, function(err) {
    console.log(err);
});
Dan Tang
  • 1,273
  • 2
  • 20
  • 35
  • Even if u reject, why send an object of Error? Send the message to log. Also, IMHO, if you are using a promise, ensure a promise error handler/callback is called and not raise/throw error. – Nagaraj Tantri Oct 08 '14 at 16:17
  • 2
    @LearningNeverStops - Error objects are very useful because they create a stack trace - I almost always use them when throwing an error like this. An invalid argument of this type is usually a programming error and you want to provide as much information as possible to the developer so they can understand what went wrong and where it went wrong. – jfriend00 Oct 08 '14 at 18:05
  • 1
    I'd love to say "always reject" since that's my opinion but there is a 20 pages long debate on this on the promises/A+ github page. Read it, voting to close as opinion based. – Benjamin Gruenbaum Oct 08 '14 at 21:20
  • Also, seconding jfriend - always reject with errors if you value sanity. Do however note you should promising at the lowest level possible. – Benjamin Gruenbaum Oct 08 '14 at 21:22
  • @BenjaminGruenbaum: Would you mind linking to that debate? However, I wouldn't close as opinion-based, but rather as a duplicate :-) Possibly related: [Why are exceptions used for rejecting promises in JS?](http://stackoverflow.com/q/21616432/1048572) and [acceptable promise pattern for 'LOUD' errors?](http://stackoverflow.com/q/17866672/1048572) on the design philosophy. – Bergi Oct 08 '14 at 22:41
  • @jfriend00 it makes sense if you code is a framework which others use or in case of debugging. But in a scenario where you have to handle the error mechanism, there is no need for stacktrace. Anyways, a perceptive thought :) – Nagaraj Tantri Oct 09 '14 at 02:28
  • You'd be surprised. It can save you a lot of time in your own code to find out where things went wrong if an exception is thrown and there's no handler for the exception nearby. It costs you little to use the Error class and it can save you a lot of time - even in your own code - at least that's been my experience. – jfriend00 Oct 09 '14 at 02:53

0 Answers0