mình làm theo cách này để custom 1 hàm try catch chung cho cả team sài, sau này đặt log trong hàm đó cũng có thể check được hết cách lỗi của tất cả cả hàm try catch trong hệ thống tiện thật sự
E nghĩ ntn, mình try catch 1 phát gói cả 3 cái await lại, Xử lý tập trung phân loại errr trong catch bằng cách tạo ra các custom exception cho từng promise để catch bắt dc
Hồi xưa mình cũng làm 1 hàm awaitWrapper y như giáo chủ vậy. Xong đến lúc code implement bị đồng nghiệp kêu làm màu, code chi dài dòng, sao không làm kiểu then.catch như kiểu level 2 trong clip. Tức quá mà cãi k lại số đông nên thôi 😂
Thì đúng là lv2 là tối ưu nhất cho mấy case ngắn như này rồi Lv3 chỉ tốt với những case xử lý logic nhiều ở 2 phần result và result thì code nó sẽ tường minh hơn lv2
mới biết tới kênh, nhờ thấy nhiều đề xuất từ kênh và thấy nội dung trên kênh thật sự chật lượng. Nhưng em góp ý nhỏ xíu là tiết tấu video nên nhanh hơn tẹo nữa thì ng xem sẽ dễ xem hơn
mình đang ko hiểu 1 chút, theo mình hiểu await nó tương đương với .then(); vậy tại sao level 2 lại await promise.then().catch()?, như vậy có thừa quá ko ạ?
@@anonystick hèn gì , anh có nhiều nghiệp vụ hay thiệt , em dev chủ yếu làm theo yêu cầu của khách hàng cho xong , chứ ít khi suy nghĩ những luồng điều kiện có thể ảnh hưởng đến prod của mình ( em làm cũng trên 3 năm rồi )
Anh owii anh có thể làm video về xử lí API vs axios trong FE khi mà call api data bị fail được không ạ... Ví dụ như cái category mà tự nhiên call data ko lên :(( Em cảm ơn anh nhiều ạ
Anh ơi cho em hỏi là viết v chuẩn hơn đúng k ạ, tại vì cách của anh nó sẽ k phân biệt đc result nào của promise nào ``` async function getData() { const [err1, result1] = await handleRequest(getApi("a")); if (err1) { console.log("loi 1", err1); } const [err2, result2] = await handleRequest(getApi("b")); if (err2) { console.log("loi 2", err2); } const [err3, result3] = await handleRequest(getApi("c")); if (err3) { console.log("loi 3", err3); } } ```
@@sometimesalways1259 trong trường hợp này dùng `promise.all` thì mình nghĩ là không thích hợp vì: nếu chỉ 1 trong 3 promise có lỗi thì vẫn sẽ nhảy vào catch làm ảnh hưởng tới 2 promise còn lại + khi có lỗi thì cũng sẽ không biết được là lỗi do promise nào nhỉ @@ mình nghĩ thế thôi cũng chưa test thử kk
nhưng làm thế thì 1 promise bị reject lại ảnh hưởng đến tất cả cái còn lại, đây là logic độc lập dù promise1 lỗi thì những promise sau vẫn hoạt động bình thường
cứ tỉ lệ 80/20 anh nhé, rất thích các video khó và sâu của anh. Chúc anh và gia đình sức khoẻ.
Ồ, một comment động lực đây rồi. Tks em nhé!
Xem video của anh rất sướng, cám ơn anh nhiều. Chúc anh và gia đình thật nhiều sức khỏe anh nhé.
OK em. Tks em!
mình làm theo cách này để custom 1 hàm try catch chung cho cả team sài, sau này đặt log trong hàm đó cũng có thể check được hết cách lỗi của tất cả cả hàm try catch trong hệ thống tiện thật sự
Ý kiến quá hay anh ơi, cảm ơn anh 🤩
level 3 giống như bên Golang handle error khá là dễ hiểu gọn gàng
video hay quá , chúc anh và gia đình sức khỏe
theo em thì vẫn nên ưu tiên cái thứ 2 hơn, dễ đọc dễ hiểu nhất cho những người đi sau dễ sửa chữa.
view đang ok hơn rồi đấy bác. Chúc bác thành công
E nghĩ ntn, mình try catch 1 phát gói cả 3 cái await lại,
Xử lý tập trung phân loại errr trong catch bằng cách tạo ra các custom exception cho từng promise để catch bắt dc
theo kinh ngiệm của mình thì trong nhiều trường hợp rất khó để xử lý nên dùng cách này là tối ưu nhất
Gói cả 3 lại khi cái trên lỗi thì cái dưới sẽ không thực hiện tiếp. Try catch riêng từng cái khi 1 cái lỗi thì các cái sau vẫn chạy
Hồi xưa mình cũng làm 1 hàm awaitWrapper y như giáo chủ vậy. Xong đến lúc code implement bị đồng nghiệp kêu làm màu, code chi dài dòng, sao không làm kiểu then.catch như kiểu level 2 trong clip. Tức quá mà cãi k lại số đông nên thôi 😂
Thì đúng là lv2 là tối ưu nhất cho mấy case ngắn như này rồi
Lv3 chỉ tốt với những case xử lý logic nhiều ở 2 phần result và result thì code nó sẽ tường minh hơn lv2
Cảm ơn bác Annoy
Tks bro!
chuổi videos của a rất hay
Cảm ơn Thắng!
e thấy cái cachs thứ 2 dễ hiểu mà ngắn gọn hơn. a làm thêm video về js đi ạ
Uhm, ok em! Tks em!
mới biết tới kênh, nhờ thấy nhiều đề xuất từ kênh và thấy nội dung trên kênh thật sự chật lượng. Nhưng em góp ý nhỏ xíu là tiết tấu video nên nhanh hơn tẹo nữa thì ng xem sẽ dễ xem hơn
Ok, cảm ơn bạn. Mình sẽ cố gắng xem lại
Thầy có thể dạy express qua hẳn dự án thực tế có phân quyền các thứ đc ko ạ.Xem thầy code quá đỉnh lun
Ối ng ae
Hay quá bác!
sao cách 3 của bác lại có 2 await liên tiếp mà vẫn chạy bình thường nhỉ?
giọng anh hay ghia ^^
Tks em! :)
Hay quá anh
qua hay
level 3 dễ nhìn quá
anh ơi tại sao ở đây lại dùng 2 cái await ạ ?
mình đang ko hiểu 1 chút, theo mình hiểu await nó tương đương với .then(); vậy tại sao level 2 lại await promise.then().catch()?, như vậy có thừa quá ko ạ?
Cách thứ 3 anh viết khá giống cách handle error trong golang
Anh cho em hỏi tại sao khi anh chạy cách 2 thì lại in ra "resolve" còn 2 cách kia không có ạ?
Do cách 2 có console.log(Resolve) đó bạn! :D
cách level 3 giống với cách xử lý error của golang, cá nhân em thích cách level 3 nhất
Cảm ơn anh đã chia sẻ kiến thức rất hay. Nhưng cho e hỏi: Ở phút 9:00, câu lệnh [error, result] = await await handleRequest(request('a')) nghĩa là gì ạ. Sao lại dùng 2 lần await vậy ạ? Rất mong anh giải đáp thắc mắc của e.
Ảnh copy dư thôi kkk
anh cho em hỏi vì sao lại phải dùng 2 cái await vậy anh, em vẫn chưa hiểu lắm. cám ơn a nhiều
Bác ấy viết dư thôi bác, 1 await là đủ
hay a
video rất hữu ích anh, không liên quan nhưng cho em hỏi kinh nghiệm làm việc của anh đã trên 10 năm chưa ạ :)))
Cảm ơn em! Anh trên con số đó em à. :)
@@anonystick hèn gì , anh có nhiều nghiệp vụ hay thiệt , em dev chủ yếu làm theo yêu cầu của khách hàng cho xong , chứ ít khi suy nghĩ những luồng điều kiện có thể ảnh hưởng đến prod của mình ( em làm cũng trên 3 năm rồi )
Trang web giup em rất nhiều, em cảm ơn !
nhìn code giống go quá :3
Nhìn kỹ đấy, y chang!
Em hay dùng level3
ở level 3 bác dùng 2 await await handlerRequest hả bác
1 cái thôi em, nhầm á :D. Sr anh em, giờ mới để ý.... Lỗi to quá :D
@@anonystick dùng 2 cái vẫn chạy được mà, thấy trong bài anh dùng 2 cái await vẫn chạy được đấy
Cho mình hỏi ở line 41, sao lại có 2 await nhỉ. Hay là tác giả viết thừa thế
1 cai thoi ban. Tac gia confirm la bi nham chut thoi
Anh owii anh có thể làm video về xử lí API vs axios trong FE khi mà call api data bị fail được không ạ...
Ví dụ như cái category mà tự nhiên call data ko lên :((
Em cảm ơn anh nhiều ạ
OK em!
Anh ơi cho em hỏi là viết v chuẩn hơn đúng k ạ, tại vì cách của anh nó sẽ k phân biệt đc result nào của promise nào
```
async function getData() {
const [err1, result1] = await handleRequest(getApi("a"));
if (err1) {
console.log("loi 1", err1);
}
const [err2, result2] = await handleRequest(getApi("b"));
if (err2) {
console.log("loi 2", err2);
}
const [err3, result3] = await handleRequest(getApi("c"));
if (err3) {
console.log("loi 3", err3);
}
}
```
sao k dùng promise.all cho gọn hơn bác nhỉ?
Đâu phải lúc nào cùng dùng `promise.all` đâu bạn.
@@anonystick mình đang nói trường hợp của bác mà, data trả về k phụ thuộc nhau thì mình dùng thui chớ pải hk bác?
@@sometimesalways1259 trong trường hợp này dùng `promise.all` thì mình nghĩ là không thích hợp vì: nếu chỉ 1 trong 3 promise có lỗi thì vẫn sẽ nhảy vào catch làm ảnh hưởng tới 2 promise còn lại + khi có lỗi thì cũng sẽ không biết được là lỗi do promise nào nhỉ @@ mình nghĩ thế thôi cũng chưa test thử kk
@@trungtang2483 ở đây có thể sử dụng Promise.allSettled([promise]) .Promise.allSettled sẽ đợi tất cả các promise trả về kết quả dù reject hay resolve
ở ví dụ 1, cho em hỏi mình có thể gộp trong 1 khối try catch và ok hơn thì xài Promise.all nữa cũng okay mà anh
nhưng làm thế thì 1 promise bị reject lại ảnh hưởng đến tất cả cái còn lại, đây là logic độc lập dù promise1 lỗi thì những promise sau vẫn hoạt động bình thường
gom 3 promise vao trong 1 try
Vào trong thì không biết của thằng nào ???
senior??
Dạ Anh! Có gì sai hả anh?