Khi nào .then (thành công, thất bại) được coi là một phản mẫu cho những lời hứa?

Tôi đã xem qua Câu hỏi thường gặp về lời hứa của bluebird , trong đó đề cập đến đó .then(success, fail)là một phản đề . Tôi hoàn toàn không hiểu lời giải thích của nó về việc thử và bắt. Điều gì sai với điều này sau đây?

some_promise_call()
.then(function(res) { logger.log(res) }, function(err) { logger.log(err) })

Có vẻ như ví dụ này gợi ý những điều sau đây là cách chính xác.

some_promise_call()
.then(function(res) { logger.log(res) })
.catch(function(err) { logger.log(err) })

Có gì khác biệt?

Có gì khác biệt?

Cuộc .then()gọi sẽ trả lại một lời hứa sẽ bị từ chối trong trường hợp cuộc gọi lại bị lỗi. Điều này có nghĩa là, khi thành công của bạn loggerthất bại, lỗi sẽ được chuyển sang cuộc .catch()gọi lại sau , nhưng không phải là failcuộc gọi lại đi cùng success.

Đây là sơ đồ luồng điều khiển :

Để thể hiện nó trong mã đồng bộ:

// some_promise_call().then(logger.log, logger.log)
then: {
    try {
        var results = some_call();
    } catch(e) {
        logger.log(e);
        break then;
    } // else
        logger.log(results);
}

Đối số thứ hai log(giống như đối số thứ nhất .then()) sẽ chỉ được thực thi trong trường hợp không có ngoại lệ xảy ra. Khối được gắn nhãn và breaktuyên bố cảm thấy hơi kỳ lạ, đây thực sự là những gì python đã try-except-elsecho (đọc khuyến nghị!).

// some_promise_call().then(logger.log).catch(logger.log)
try {
    var results = some_call();
    logger.log(results);
} catch(e) {
    logger.log(e);
}

Trình catchghi nhật ký cũng sẽ xử lý các trường hợp ngoại lệ từ cuộc gọi logger thành công.

Quá nhiều cho sự khác biệt.

Tôi không hiểu lời giải thích của nó về việc thử và bắt

Đối số là thông thường bạn muốn bắt lỗi trong mỗi bước xử lý và bạn không nên sử dụng nó trong chuỗi. Kỳ vọng là bạn chỉ có một trình xử lý cuối cùng xử lý tất cả các lỗi - trong khi, khi bạn sử dụng "antipotype", các lỗi trong một số cuộc gọi lại sau đó không được xử lý.

Tuy nhiên, mẫu này thực sự rất hữu ích: Khi bạn muốn xử lý các lỗi xảy ra trong chính xác bước này và bạn muốn làm một cái gì đó hoàn toàn khác khi không có lỗi xảy ra - tức là khi lỗi không thể phục hồi. Hãy lưu ý rằng điều này đang phân nhánh luồng kiểm soát của bạn. Tất nhiên, điều này đôi khi là mong muốn.

Điều gì sai với điều này sau đây?

some_promise_call()
.then(function(res) { logger.log(res) }, function(err) { logger.log(err) })

Rằng bạn phải lặp lại cuộc gọi lại. Bạn muốn

some_promise_call()
   .catch(function(e) {
       return e; // it's OK, we'll just log it
   })
   .done(function(res) {
       logger.log(res);
   });

Bạn cũng có thể xem xét sử dụng .finally()cho việc này.

Cả hai không hoàn toàn giống nhau. Sự khác biệt là ví dụ đầu tiên sẽ không bắt gặp một ngoại lệ được đưa vào successxử lý của bạn . Vì vậy, nếu phương thức của bạn chỉ nên trả lại các lời hứa đã được giải quyết, như thường lệ, bạn cần một catchtrình xử lý theo dõi (hoặc một phương thức khác thencó successtham số trống ). Chắc chắn, có thể là thentrình xử lý của bạn không làm bất cứ điều gì có khả năng thất bại, trong trường hợp sử dụng một tham số 2 thencó thể tốt.

Nhưng tôi tin rằng điểm của văn bản bạn liên kết đến là thenhầu như hữu ích so với các cuộc gọi lại trong khả năng của nó để xâu chuỗi một loạt các bước không đồng bộ và khi bạn thực sự làm điều này, dạng 2 tham số của thentinh tế không hoạt động như mong đợi , vì lý do trên. Nó đặc biệt phản trực giác khi được sử dụng giữa chuỗi.

Là một người đã thực hiện rất nhiều công cụ không đồng bộ phức tạp và va vào các góc như thế này nhiều hơn tôi quan tâm, tôi thực sự khuyên bạn nên tránh mô hình chống này và đi theo phương pháp xử lý riêng.

Bằng cách xem xét các ưu điểm và nhược điểm của cả hai, chúng ta có thể đoán được tính toán phù hợp với tình huống. Đây là hai cách tiếp cận chính để thực hiện lời hứa. Cả hai đều có điểm cộng và điểm trừ

Cách tiếp cận bắt

some_promise_call()
.then(function(res) { logger.log(res) })
.catch(function(err) { logger.log(err) })

Ưu điểm

1. Tất cả các lỗi được xử lý bởi một khối bắt.
2. Thậm chí bắt bất kỳ ngoại lệ trong khối sau đó.
3. Chuỗi nhiều cuộc gọi lại thành công

Nhược điểm

1. Trong trường hợp xâu chuỗi, việc hiển thị các thông báo lỗi khác nhau trở nên khó khăn.

Cách tiếp cận thành công / lỗi

some_promise_call()
.then(function success(res) { logger.log(res) },
      function error(err) { logger.log(err) })

Ưu điểm

1. Bạn có được kiểm soát lỗi hạt mịn.
2. Bạn có thể có chức năng xử lý lỗi phổ biến cho các loại lỗi khác nhau như lỗi db, lỗi 500, v.v.

Biến mất

1. Bạn vẫn sẽ cần một cái khác catchnếu bạn muốn xử lý các lỗi được gọi bởi cuộc gọi lại thành công

Giải thích đơn giản:

Trong ES2018

Khi phương thức bắt được gọi với đối số onRejection, các bước sau được thực hiện:

1. Hãy để lời hứa là giá trị này.
2. Trở về ? Gọi (lời hứa, "sau đó", «không xác định, bị từ chối»).

Điều đó có nghĩa là:

promise.then(f1).catch(f2)

bằng

promise.then(f1).then(undefiend, f2)

Việc sử dụng .then().catch()cho phép bạn kích hoạt Promise Chaining cần thiết để hoàn thành quy trình công việc. Bạn có thể cần phải đọc một số thông tin từ cơ sở dữ liệu sau đó bạn muốn chuyển nó sang API async sau đó bạn muốn thao tác phản hồi. Bạn có thể muốn đẩy phản hồi trở lại cơ sở dữ liệu. Xử lý tất cả các quy trình công việc này với khái niệm của bạn là có thể thực hiện được nhưng rất khó quản lý. Giải pháp tốt hơn sẽ là then().then().then().then().catch()nhận tất cả các lỗi chỉ trong một lần bắt và cho phép bạn giữ khả năng duy trì của mã.

Sử dụng then()và catch()giúp chuỗi thành công và xử lý thất bại trên lời hứa. catch()làm việc trên lời hứa được trả lại bởi then(). Nó xử lý,

1. Nếu lời hứa bị từ chối. Xem số 3 trong hình
2. Nếu xảy ra lỗi trong trình xử lý thành công của then (), giữa các số dòng 4 đến 7 dưới đây. Xem # 2.a trong hình (Lỗi gọi lại then()không xử lý việc này.)
3. Nếu xảy ra lỗi trong trình xử lý lỗi của (), dòng số 8 bên dưới. Xem # 3.b trong hình.

1. let promiseRef: Promise = this. aTimetakingTask (false); 2. promiseRef 3. .then( 4. (result) => { 5. /* successfully, resolved promise. 6. Work on data here */ 7. }, 8. (error) => console.log(error) 9. ) 10. .catch( (e) => { 11. /* successfully, resolved promise. 12. Work on data here */ 13. });

Lưu ý : Nhiều lần, trình xử lý lỗi có thể không được xác định nếu đã catch()được viết. EDIT: reject()kết quả trong cách gọi catch()chỉ khi xử lý lỗi trong then()là không xác định. Thông báo số 3 trong hình tới catch(). Nó được gọi khi trình xử lý trong dòng # 8 và 9 không được xác định.

Điều này có ý nghĩa bởi vì lời hứa được trả lại bởi then()không có lỗi nếu một cuộc gọi lại chăm sóc nó.

Thay vì lời nói, ví dụ tốt. Mã sau (nếu lời hứa đầu tiên được giải quyết):

Promise.resolve()
.then
(
  () => { throw new Error('Error occurs'); },
  err => console.log('This error is caught:', err)
);

giống hệt với:

Promise.resolve()
.catch
(
  err => console.log('This error is caught:', err)
)
.then
(
  () => { throw new Error('Error occurs'); }
)

Nhưng với lời hứa đầu tiên bị từ chối, điều này không giống nhau:

Promise.reject()
.then
(
  () => { throw new Error('Error occurs'); },
  err => console.log('This error is caught:', err)
);

Promise.reject()
.catch
(
  err => console.log('This error is caught:', err)
)
.then
(
  () => { throw new Error('Error occurs'); }
)