Рекурсивное обещание не продолжается, а затем блокируется при вызове [дубликат]

Ну, в случае локальной переменной ясно, что это означает «раньше», поскольку поток программы между объявлением (в методе) и ссылкой является последовательным. В случае, если поля, объявленные вне компилятора метода, никогда не знают, какой код будет использоваться, когда он не сможет сгенерировать ошибку, поскольку, возможно, какой-либо другой метод будет инициализировать поле до его использования.

45
задан Pipo 3 November 2014 в 10:27
поделиться

1 ответ

В отличие от обоих ответов в комментариях - есть разница.

Хотя

Promise.resolve(x);

в основном совпадает с

new Promise(function(r){ r(x); });

, там является тонкостью.

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

Учитывая это - когда спецификация была создана, конструктор обещаний выбрасывает сейф.

Что если someObject есть undefined?

  • Путь A возвращает отклоненное обещание.
  • Путь B синхронно бросается.

Bluebird увидев это, и Петка добавил Promise.method, чтобы решить эту проблему, чтобы вы могли продолжать использовать возвращаемые значения. Таким образом, правильный и простой способ написать это в Bluebird на самом деле не так: это:

var someFunction = Promise.method(function someFunction(someObject){
    someObject.resolved = true;
    return someObject;
});

Promise.method будет конвертировать броски для отклонения и возврата к разрешению для вас. Это самый безопасный способ бросить это, и он ассимилирует then ables через возвращаемые значения, чтобы он работал, даже если someObject на самом деле является обещанием.

В общем случае Promise.resolve используется для сдачи объектов и иностранных обещаний (thenables) для обещаний. Это его прецедент.

50
ответ дан Dmitri Zaitsev 16 August 2018 в 11:04
поделиться
  • 1
    «Функции возврата обещаний должны, как правило, иметь гарантию, что они не должны бросать синхронно, так как они могут асинхронно переключаться». Не могли бы вы объяснить, почему функции должны быть либо синхронными, либо асинхронными, но не тем и другим? В настоящее время мне нравится Promise.resolve (). Не могли бы вы сказать, что использование Promise.resolve() является анти-шаблоном? – Ashley Coolman 28 January 2016 в 13:50
  • 2
    @AshleyCoolman см. blog.izs.me/post/59142742143/designing-apis-for-asynchrony - метод, который иногда ведет асинхронно, должен всегда сделайте это для согласованности. – Benjamin Gruenbaum 28 January 2016 в 15:05
  • 3
    Создает ли Promise.resolve() новый экземпляр Promise так же, как с помощью new? Если нет, return Promise.resolve(yourCode) будет быстрее и избежать синхронных бросков. – Steven Vachon 12 February 2016 в 04:30
  • 4
    Мне плохо, я использую & quot; Promise.resolve (), а затем (function () {/ * case, который может вызывать ошибку * /}), затем ... & quot; чтобы ошибка стала отвергаемым обещанием ... Я больше посмотрю на «Promise.method». – Polopollo 24 August 2016 в 18:32
  • 5
    @Polopollo или Promise.coroutine, что еще более полезно. – Benjamin Gruenbaum 24 August 2016 в 19:51
Другие вопросы по тегам:

Похожие вопросы: