作者:微信小助手
发布时间:2022-10-19T15:36:08
开发中无论怎样都会产生网络请求,这样一来自然也就避免不了大量使用 首先最常用的两种处理网络请求的形式即 但如果涉及嵌套请求,那可能还要不断的增加 那恐怕不得不让 之所以写作本篇文章是因为在优化数据库操作时,发现要不停 家在吉林的小明想去海南看望他的老奶奶,但小明觉得旅途如此之长,不如先去山东学习学习马保国老师的“接化发”,然后再去云南拍一个“我是云南的 云南怒江的... ”的视频发一下朋友圈,最后再去海南看望老奶奶 请你运用所学知识帮帮小明,查询 注意,当确定吉林-山东的车票未售空时才去查询山东-云南的车票是否已售空,并以此类推;因为这样的话,小明可以知道是哪个地方的车票没有了,并及时换乘 虽然吉林--山东--云南--海南的车票可以一次性查询完毕,但为了体现嵌套请求的复杂度,我们此处不讨论并发请求的情况,关于并发,你可以使用 先来细化题目,可以看到路线依次为:吉林-山东、山东-云南、云南-海南,也就分别对应三个请求,且这三个请求又是嵌套发出的。而每次发出的请求,最终都会有两种情况:请求成功/失败, 之所以请求失败对应车票已售空,是为了模拟请求失败的情况,而不是通过返回一个标识来代表本轮次车票是否已售空 这个令人头疼的需求,我建议你再认真读一遍 为了简单起见,这里就不额外开启一台服务器了,转而使用定时器模拟异步任务 以下是用于查询车票的接口,我们称之为 在下文中所指的请求函数就是requestJS、requestSY、requestYHthen
、catch
或try catch
来捕获错误,而捕获错误的代码量是随着网络请求的增多而增多,那应该如何优雅的系统性捕获某个网络请求中所产生的所有错误呢?Promise
与async
(事实上很多请求库都是基于这两者的封装),使用Promise
那必然要与then
、catch
挂钩,也就是说每个请求都对应一个Promise
实例,然后通过该实例上对应的方法来完成对应的操作,这应该算是比较常用的一种形式了then
、catch
来完成需求,好了,现在可以使用看起来真的像同步编程的async
来着手优化了,即await promise
,那这种情况下就根本不需要手动then
了,但如果await promise
抛出了错误呢?try catch
来帮忙了,而如果也是嵌套请求,那与Promise
写法类似的问题又来了,有多少次请求难道我就要多少次try catch
吗?那这样看来的话,Promise
与async
在面对这种屎山请求的时候确实有点心有余而力不足了前言
try catch
,且操作数据库的代码越多,则try catch
就越多,于是突发奇想,能不能封装一个工具类来实现智能化捕获错误呢?在这种思维的推动下,我觉得这个工具类不仅仅是以一种创意的形式出现,更多的是实用性!(先不考虑这个创意能否实现)一个令人头疼的需求
吉林--山东--云南--海南
的车票还有吗?
本次所有车票的开销是多少
可能会换个路线
去找老奶奶
Promise.all
请求成功则代表本轮次车票未售空
,请求失败则代表本轮次车票已售空
准备工作
请求函数
// 标识每次请求的成功与否(吉林-山东、山东-云南、云南-海南)
const interface = [true, true, true]
// 查询 吉林-山东 的车票是否已售空的接口
const requestJS = () => new Promise((res, rej) => {
setTimeout(() => {
// 请求成功(resolve)则代表车票未售空
if (interface[0]) return res({ ticket: true, price: 530, destination: '吉林-山东' })
// 请求成功(rejected)则代表车票已售空
rej({ ticket: false, destination: '吉林-山东' })
}, 1000)
})
// 查询 山东-云南 的车票是否已售空的接口
const requestSY = () => new Promise((res, rej) => {
setTimeout(() => {
if (interface[1]) return res({ ticket: true, price: 820, destination: '山东-云南' })
rej({ ticket: false, destination: '山东-云南' })
}, 1500)
})
// 查询 云南-海南 的车票是否已售空的接口
const requestYH = () => new Promise((res, rej) => {
setTimeout(