Ưu điểm của việc sử dụng sai sót là gì?

Question

Các lập trình viên dường như bị phân chia về cách nhận thông báo không đồng bộ về lỗi.

Một số lập trình viên muốn sử dụng gọi lại với hai đối số: giá trị và boolean cho biết giá trị có sai không. Điều này có lợi ở chỗ nó trông giống như một tuyên bố try catch:

asyncFunct(function (value, noError) { 
    if (noError) { 
     // success, do something with value 
    } else { 
     // value is the error which is thrown 
    } 
}); 

số khác lại thích sự tiêu cực (ví dụ: boolean nên nói cho dù giá trị là sai lầm). lập luận của họ là nếu bạn biết rằng chức năng không đồng bộ sẽ không bao giờ ném ra một lỗi sau đó bạn có thể yên tâm bỏ qua tham số thứ hai như sau:

asyncFunction(function (value, isErroneous) { 
    if (!isErrorneous) { 
     // success, do something with value 
    } else { 
     // value is the error which is thrown 
    } 
}); 

asyncFunction(function (value) { 
    // success, do something with value 
}); 

Sau đó, có những người đề xuất callbacks riêng biệt để thực hiện thành công các chức năng đồng bộ và errbacks để thực hiện sai các chức năng không đồng bộ. Điều này cho phép các lập trình viên để chọn nếu anh muốn xử lý callbacks, errbacks, cả hoặc không có gì:

asyncFunction(function (value) { 
    // success, do something with value 
}, function (error) { 
    // handle the error 
}); 

asyncFunction(function (value) { 
    // success, do something with value 
}); 

asyncFunction(null, function (error) { 
    // handle the error 
}); 

Tôi không yêu cầu cho phương pháp nào bạn thích. Tôi chỉ đơn giản là yêu cầu những lợi thế và bất lợi của mỗi phương pháp để tôi biết cái nào để sử dụng khi nào.

Answer 1

Thiết kế Quyết định:

này chỉ được thiết kế quyết định, không có gì hơn. Nếu đó là tham số độc lập, bạn có thể có chức năng độc lập và tạo mã "đẹp hơn" (đối với ai đó - cho ai đó lộn xộn hơn - đó thực sự là chủ quan).

Lỗi phức tạp:

Trong một số ứng dụng mà bạn có thể có lỗi phức tạp hơn (filesystem.fileRead thể có FILE_DONT_EXISTS, FILE_LOCKED, NOT_PERMISSIONS ..) và trong một số ứng dụng bạn chỉ cần ném lỗi (db.checkConnection hoặc db.openConnection).

Trình tự, sự khác biệt:

mẫu Very nice for the API tuyệt vời là từ Amazon, bạn có thể kiểm tra xem nó. http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/S3.html

ỨNG PHÓ: On asynch chức năng như copyObject(params = {}, callback) bạn có chức năng gọi lại, có luôn 2 thông số: err (Error) và data (Object) trong function(err, data) { ... }. Lỗi được thiết kế giống như tham số đầu tiên bởi vì nếu bạn có lỗi, bạn không có dữ liệu. Vì vậy, nó thực sự là về ưu tiên và về trật tự.

// request 

getObject({ 
    param1 : something, 
    param2 : something, 
    param3 : something 
}, callback); 

// response 

function callback(error, response){ 
    if error throw err; 
    // now deal with responsei 
} 

Như bạn có thể thấy, bạn có cả hai cách hỗn hợp. Trong yêu cầu bạn vượt qua đối tượng và chức năng và trong phản ứng bạn nhận được lỗi và đối tượng (để chức năng yêu cầu đó).