вопрос по промисам

catch(cb) — это сахар над then(undefined, cb).

но я так и не понял, зачем все таки reject, если и без него ошибка передается куда надо?

Допустим если ошибка в логике самой программы (если так можно выразиться).

var promise = new Promise(function (resolve, reject) {
    var ajaxResult = { // образно
        'status': 'error',
        'message': 'Неправильный логин или пароль'
    };
    
    switch (ajaxResult.status) {
        case 'error':
                reject(ajaxResult.message);
                break;
        case 'success':
                resolve();
    }
});

promise.then(function() {
    alert('Добро пожаловать!');
},
function (e) {
    alert('Ошибка: ' + e);
});

вместо этого можно просто генерировать ошибку, так?

Затем, что она передаётся в ближайший reject.

Ну генерируй, просто это уже не будет в стиле Promise имхо.

А что, если reject необходимо сделать из какого-то другого контекста, в коллбеке от какой-то асинхронной функции?

Затем, что она передаётся в ближайший reject.

Также, как и любая выброшенная (throw) ошибка.

Ну генерируй, просто это уже не будет в стиле Promise имхо.

Нет ничего плохого, чтобы выбрасывать ошибки внутри промисов вместо вызова reject, это часть спецификации Promise.

Точно также, как вместо resolve(data) можно писать return data; и оно упадёт в следующий then(function(data) {...}).

Кстати, с AJAX'ом хороший пример, только неполный, ответ от сервера придёт ведь уже после завершения метода, в котором создаётся Promise и производится запрос, в коллбеке с ответом только reject/resolve'ом справиться можно.

UPD: идея в том, что reject — функция, её можно передать в какой-нибудь внешний код или вызвать в асинхронном коллбеке, передав через замыкание. То есть, вызвать уже после завершения функции, в которой создаётся Promise (когда throw уже делать бесполезно).

Затем, что она передаётся в ближайший reject.

ты наверное, имел в виду, ближайший catch. Ну так, она и так туда передается.

функция, её можно передать в какой-нибудь внешний код или вызвать в асинхронном коллбеке, передав через замыкание. То есть, вызвать уже после завершения функции, в которой создаётся Promise (когда throw уже делать бесполезно).

Да, наверное так и есть, спасибо. Только вот, едва ли стоит так делать, это возврат к callback-hell, по сути. Лучше этого избегать.

Так приходится делать, когда нужно обернуть в Promise какой-нибудь асинхронный вызов, который не возвращает Promise'ы. Все стандартные методы, тот же xhr, пока ещё не реализованы через Promise'ы.

Также, иногда, нужно писать какую-нибудь сложную логику, где, то, что под капотом Promise'а отложено намеренно и реальное время его выполнения зависит от третьего фактора (от доступности какого-нибудь сервиса, например), тогда, правильным использованием Promise'а можно красиво обернуть эти вызовы, избавив внешний код от проверок доступности этого сервиса и написания логики ожидания доступности (как будет доступен и вызов будет выполнен — упадёт результат в then, а до того момента просто подождёшь).

Блин, catch и reject - одно и то же. Вот здесь же ответили.

catch и reject - одно и то же

Нет.

reject — отклонить

catch — отловить

Обычно, reject — метод в Promise, который нужно вызвать, когда ты хочешь информировать внешний код о том, что выполнение асинхронной операции завершилось неудачей.

cath — метод, который внешний код может вызвать у Promise, который возвращает твоя функция, передать туда коллбек, в который упадёт то, что ты передашь в reject (или выкинешь в throw).

И передаётся оно в ближайший catch, а в том комментарии вообще не о том написано.

Но, никто не запрещает тебе переменную в Promise назвать catch. Или сохранить метод промиса catch в его же поле reject :-)

едва ли стоит так делать

Вообще, мы забываем, что промисы нужны для оборачивания асинхронных операций, в этом случае return'ы и throw'ы не пройдут.

А если операция несинхронная, то на кой тебе вообще Promise'ы?

Кроме случаев, когда ты оборачиваешь в Promise сложную логику, где в одной из веток производится асинхронный вызов, а в другой — нет.

Ну да, сейчас проверил, выбрасывание ошибки из асинхронного кода не перехватывается в промисовском catch, так что reject по-любому нужен, да, иначе смысла особого нет.

WAT!?

The catch() method returns a Promise and deals with rejected cases only. It behaves the same as calling Promise.prototype.then(undefined, onRejected).

Вообще-то, должно ловиться.

не ловиться. Вот код

new Promise(function(resolve, reject){setTimeout(function(){reject(new Error("ERR_FROM_REJECT"))})})
 .catch(function(err){console.log(err); console.log("more...")}) 

new Promise(function(resolve, reject){setTimeout(function(){throw new Error("ERR_JUST_THROWN")}, 5000)})
 .catch(function(err){console.log(err); console.log("more...")}) 



//>>>> [Error: ERR_FROM_REJECT]
//>>>> more...
//>>>> new Promise(function(resolve, reject){setTimeout(function(){throw new Error("E
//>>>>                                                                   ^
//>>>> Error: ERR_JUST_THROWN

А я что написал?

очевидно, что onRejected != reject. А автор говорит именно о reject.

Вообще-то, должно ловиться.

Эм. Вообще-то, нет. Если, по-вашему мнению, должно, потрудитесь объяснить, почему.

Ой, да, точно. Утро, пойду кофе выпью.

Да, видимо, всё-таки, нужен. Ох уж этот ES 2015.

Да я уже понял, что все вопросы неправильно интерпретировал.

На Хабре наткнулся на хорошую статью по Promise.

Вкратце:

// Удобно начинать с пустого значения:
Promise.resolve()
    .then(function () {
        // Ваш код
    })
    // И ловить все ошибки в отдельном catch (в конце).
    .catch(function (err) {
        // Обработка ошибки
    });

Проблема с двумя callback'ами в `.then()` — в том, что второй не сможет отловить синхронную ошибку в первом.

А какой смысл лепить внутри промисов синхронный код?

Чтобы использовать один инструмент, когда нужно, к примеру, получить данные пользователя (асинхронно), обработать их и привести к нужному на клиенте виду (синхронно), отобразить их (синхронно), запросить Твиттер этого пользователя (асинхронно), добавить его на страницу (синхронно).

Чтобы использовать один инструмент, когда нужно, к примеру, получить данные пользователя (асинхронно), обработать их и привести к нужному на клиенте виду (синхронно)

В твоем утверждении содержится противоречие. Обработка полученных асинхронно данных является асинхронной операцией. Ошибки из такого кода будут ловиться в также асинхронно.

Ща тебя наш дурачок жизни поучит :)

Перевод на Хабре или оригинал.

Похоже, статью писал какой-то дебил

В чем разница между этими четырьмя вариантами использования промисов?

doSomething().then(function () {
  return doSomethingElse();
});

doSomething().then(function () {
  doSomethingElse();
});

doSomething().then(doSomethingElse());

doSomething().then(doSomethingElse);

Если кто-то не может ответить на этот вопрос, то он не знает не промисы, он не знает JS как таковой.

JS? это такая хрень для рисования менюшек, встроенная в браузерах, и для создания выпрыгивающих котиков на страницках? Зачем его нормальным людям знать вообще? Есть же веб-макаки.

Ну, да, нормальные люди не отличают вызов функции от самой функции, это норма.

BTW, тут можешь сделать s/JS/программирование.

Эко бомбит дауна.

Научился уже примитивы от объектов отличать?

Кажется, зря я разбудил этот тред. Благими намерениями...

Советую поучиться читать сообщения, прежде чем отвечать на них.

Приведи пример, простой, что ты имел в виду. Тогда будет о чем разговаривать. Как его можно прочитать по другому, хз, если ты собрался синхронно обрабатывать данные, пришедшие асинхронно. Либо сражу скажи, «я нахожусь на одной ступени эволюции с пользователем Vit», и тогда вопрос будет исчерпан. И не надо грубить, я тебе не грубил.

Присоединяюсь к вопросу, хотелось бы услышать, что имелось в виду, под синхронной обработкой асинхронных данных.

Скоро ты научишься узнавать этого сказочного персонажа по первой фразе той херни, которую он несет.

Ты еще не обтек после последнего раза? Или всю жизнь кирпичами срать будешь?

Я чота пропустил? анонiмус пытался забодать серьезного дядьку? И теперь анонiмус щитает себя невесть кем? Ути-пути какой.

Опять влажные кутузовские фантазии, дурачок?

Если кто-то не может ответить на этот вопрос, то он не знает не промисы, он не знает JS как таковой.

Но судя по твоему ОПу, ты как раз не можешь (или не мог) ответить на этот вопрос.

Да не, в ОП совершенно другой вопрос, чувак.

Ты просто не читал статью и самостоятельно не можешь допереть до сути вопроса.

«Статью писал неуч, который нихрена не понимает, он идиот и не понял» (с) Очевидно же.

Если бы в статье было что то стоящее, она не начиналась бы с подобной параши. А если бы с тобой о чем то можно было говорить, ты бы не читал подобные статьи, ибо, для того чтобы понять, что перед тобой говно, не надо изучать его под микроскопом. Поэтому, диалог прекращаю.

Опять тебя на влаге переклинило? Опять по кругу?

Ты с очередного аккаунта поучаешь про круги? Прямо как в анекдоте про ковбоев - ничуть не изменился.

Может быть ты и прав, для человека, задающего вопросы, на которые можно найти ответ в гугле за несколько минут, статья и правда может оказаться непонятным говном, но тем не менее там дан ответ на твой вопрос, иначе бы я не стал постить ссылки. Может быть кому-нибудь более разумному пригодятся.

Нахрен ты что то постил, если все уже решено, ты тред читал? И на тема, вроде стоит флаг «решено»