首页
沸点
课程
数据标注
HOT
AI Coding
更多
直播
活动
APP
插件
直播
活动
APP
插件
搜索历史
清空
创作者中心
写文章
发沸点
写笔记
写代码
草稿箱
创作灵感
查看更多
登录
注册
确定删除此收藏集吗
删除后此收藏集将被移除
取消
确定删除
确定删除此文章吗
删除后此文章将被从当前收藏集中移除
取消
确定删除
编辑收藏集
名称:
描述:
0
/100
公开
当其他人关注此收藏集后不可再更改为隐私
隐私
仅自己可见此收藏集
取消
确定
处理回调地狱
订阅
gate
更多收藏集
微信扫码分享
微信
新浪微博
QQ
3篇文章 · 0订阅
我删光了项目里的 try-catch,老板:6
相信我们经常这样写bug(不是 👇: 看似没问题 每个接口都要 try-catch,太啰嗦了! 错误处理逻辑分散,不可控! 代码又臭又长💨! 💡 目标:不抛异常的安全请求封装 👇
一个前端面试官的思考:当Promise遇上真实业务场景
作为一名前端面试官,我经常遇到这样的候选人:聊 Promise API 的时候说的很溜,我感觉我都没他这么溜,然后再问实际的 Promise 业务场景的时候就不会说了。今天我想分享一个常见的面试题:如
多个API嵌套应该怎么操作才更加优雅、更加方便、更加润?
这是绝对错误的写法,在async、await的语法糖支持下,下面写法的问题 不直观 优秀的代码应该直观 错误处理时也不够直观 除非所有的错误后端处理 本次考虑前端处理错误提示 可复用,可扩展的能力低