Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
沒想過的前端錯誤處理可能比你有做的還多
Search
LINE Developers Taiwan
PRO
March 18, 2024
Technology
1
86k
沒想過的前端錯誤處理 可能比你有做的還多
Speaker: Yu Chen
Event: SITCON 2024
LINE Developers Taiwan
PRO
March 18, 2024
Tweet
Share
More Decks by LINE Developers Taiwan
See All by LINE Developers Taiwan
Live Activities in LINE
line_developers_tw
PRO
0
9
Neumorphism x Liquid Glass
line_developers_tw
PRO
0
10
猜你喜歡 – 打造高度擴展的個人化電商推薦
line_developers_tw
PRO
0
21
打造新電商搜尋體驗- 搜尋意圖辨識
line_developers_tw
PRO
0
7
比價群組
line_developers_tw
PRO
0
11
從混亂到優雅,讓專案不再失控:ATDD 與 Clean Architecture 的後端實戰之路
line_developers_tw
PRO
0
10
2049智能共存:透過LINE Bot Agent迎接後人類時代
line_developers_tw
PRO
0
36
菸酒生在 LINE Taiwan 的後端雙刀流
line_developers_tw
PRO
0
1.4k
讓測試不再 BB! 從 BDD 到 CI/CD, 不靠人力也能 MVP
line_developers_tw
PRO
0
1.5k
Other Decks in Technology
See All in Technology
Skrub: machine-learning with dataframes
gaelvaroquaux
0
120
Rustから学ぶ 非同期処理の仕組み
skanehira
1
130
2025年にHCP Vaultを学び直して見えた景色 / Lessons and New Perspectives from Relearning HCP Vault in 2025
aeonpeople
0
230
AWSで推進するデータマネジメント
kawanago
1
1.2k
落ちる 落ちるよ サーバーは落ちる
suehiromasatoshi
0
150
これでもう迷わない!Jetpack Composeの書き方実践ガイド
zozotech
PRO
0
270
COVESA VSSによる車両データモデルの標準化とAWS IoT FleetWiseの活用
osawa
1
250
[ JAWS-UG 東京 CommunityBuilders Night #2 ]SlackとAmazon Q Developerで 運用効率化を模索する
sh_fk2
3
360
バッチ処理で悩むバックエンドエンジニアに捧げるAWS Glue入門
diggymo
3
180
AI開発ツールCreateがAnythingになったよ
tendasato
0
120
AI駆動開発に向けた新しいエンジニアマインドセット
kazue
0
330
「全員プロダクトマネージャー」を実現する、Cursorによる仕様検討の自動運転
applism118
10
4.4k
Featured
See All Featured
Rebuilding a faster, lazier Slack
samanthasiow
83
9.2k
Gamification - CAS2011
davidbonilla
81
5.4k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.5k
Designing Experiences People Love
moore
142
24k
Building a Modern Day E-commerce SEO Strategy
aleyda
43
7.6k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
139
34k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Mobile First: as difficult as doing things right
swwweet
224
9.9k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
We Have a Design System, Now What?
morganepeng
53
7.8k
Writing Fast Ruby
sferik
628
62k
Transcript
沒想過的前端錯誤處理 可能比你有做的還多
YU LINE Taiwan Content Dev TECHFRESH 北科資⼯⼤四 SITCON 2022 ⾏銷組組員
為什麼我今天會想分享這個主題? 加分條件 1. 使⽤ TypeScript 2. 未使⽤現成的 GitHub API client(Octokit)串接
GitHub API 3. 有處理例外狀況(Error handling) 4. 有 deploy ⾄線上環境
⼤部分⼈能想到的作法 1 try … catch 2 顯⽰錯誤訊息 給使⽤者看 3 輸出到
console ⽅便⾃⼰ debug
我們能做的更好 嗎?
有做好例外處理的程式應該要... 對使⽤者來說 對開發者來說 有整合監控系統記錄錯誤 有容錯能⼒(Fault tolerance) 圖片來源:Flaticon.com
LINE-Pay(v)_W238_n.png 什麼是容錯能⼒( Fault tolerance )? 例⼦:餐廳收款系統 圖片來源:Flaticon.com、LINE Pay 官網
為什麼我們需要錯誤監控系統? 圖片來源:Flaticon.com
⽬前市⾯上有的錯誤監控服務 圖片來源:Sentry、The LINUX Foundation、 WIKIPEDIA 、GitHub、DATADOG
Sentry 功能介紹
什麼是 Sentry? 圖片來源:Flaticon.com 開源可⾃架 前端主流的監控服務之⼀
常⽤的基本功能 1 錯誤資訊⾴⾯ 2 錯誤搜尋 3 即時錯誤通知
常⽤的基本功能 1 錯誤資訊⾴⾯ 2 錯誤搜尋 3 即時錯誤通知
基本偵錯資訊 Sentry: Scopes and Hubs
Stack Trace
Source Map Sentry: Source Maps
Breadcrumbs
詳細錯誤資訊
相關統計數據
有錯誤資訊⾴⾯的好處 提昇修復 bug 的效率 幫助我們判斷處理的 優先度 圖片來源:Flaticon.com
常⽤的基本功能 1 錯誤資訊⾴⾯ 2 錯誤搜尋 3 即時錯誤通知
錯誤搜尋
常⽤的基本功能 1 錯誤資訊⾴⾯ 2 錯誤搜尋 3 即時錯誤通知
Discord 即時通知 Sentry → Discord
官⽅整合設定
也可以透過 WebHook DIY
設定錯誤通知條件
即時通知的好處 能整合我們常⽤的 通訊軟體做到即時通知 在使⽤者/客⼾回報問題前 就能主動進⾏修復 圖片來源:Flaticon.com
聽起來好像很厲害,這樣我們還需要 try catch 和顯⽰錯誤訊息嗎? 圖片來源:風傳媒
我們仍然需要 try catch 以及各個前端框架的錯誤捕獲機制來做錯誤處理 圖片來源:Flaticon.com
也需要錯誤訊息,這對使⽤者體驗(UX)很重要 圖片來源:Flaticon.com
捕獲程式發⽣的錯誤 顯⽰錯誤訊息 給使⽤者看 將錯誤記錄 到監控系統
捕獲程式發⽣的錯誤 顯⽰錯誤訊息 給使⽤者看 將錯誤記錄 到監控系統
瀏覽器 / 原⽣ JavaScript 前端框架 錯誤捕獲機制 圖片來源:WIKIPEDIA
錯誤捕獲機制 瀏覽器 / 原⽣ JavaScript 圖片來源:WIKIPEDIA 1. try ... catch
2. Promise.Prototype.catch() 3. window.onerror
window.onerror
五個參數的⽤途
前端框架的錯誤捕獲機制 getDerivedStateFromError componentDidCatch onErrorCaptured handleError 圖片來源:WIKIPEDIA
<ErrorBoundary /> can help you ErrorBoundary
如何實作 ErrorBoundary getDerivedStateFromError componentDidCatch onErrorCaptured handleError <ErrorBoundary /> 圖片來源:WIKIPEDIA
ErrorBoundary 介⾯定義 State: • hasError: false Props: • children •
fallback(顯⽰錯誤訊息的元件)
ErrorBoundary 實作邏輯 渲染 children 時 有沒有發⽣錯誤 檢查 hasError 的狀態 true
開始渲染 渲染 fallback false 沒有 正常顯⽰ children 將 hasError 設成 true,並做錯誤處理 有
什麼元件需要⽤ ErrorBoundary 包? 當壞掉時 不會影響其他在元件樹上 同層的元件運作的元件 網⾴程式的進入點
為什麼進入點需要包 ErrorBoundary? 圖片來源:Flaticon.com
“當壞掉時,不會影響其他在元件樹上同 層的元件運作的元件。” 這句話是什麼意思?
ErrorBoundary 圖片來源:Flaticon.com
如果每個都包會有什麼問題? • 不是所有元件都需要包 ErrorBoundary • 會影響效能 • 可能會產⽣不好的使⽤者體驗
壞⼀半的 UI === 全壞爛的 UX ErrorBoundary
壞⼀半的 UI === 全壞爛的 UX
那要怎麼判斷呢?
當這個元件壞掉時, 其他同層的元件該跟著消失嗎? 遍歷整顆元件樹,並對每個元件問這個問題
以 X 為例⼦模擬⼀遍
以 X 為例⼦模擬⼀遍
捕獲程式發⽣的錯誤 顯⽰錯誤訊息 給使⽤者看 將錯誤記錄 到監控系統
顯⽰錯誤訊息實作
捕獲程式發⽣的錯誤 顯⽰錯誤訊息 給使⽤者看 將錯誤記錄 到監控系統
將錯誤紀錄到 Sentry 當程式進到 try...catch 的 catch 區塊時 ErrorBoundary 中發⽣ 錯誤時觸發的
hook
可能會拋出錯誤的 function 第三⽅ library 中 ⽂件明確寫出可能會拋出 錯誤的 function 開發團隊⾃⼰寫 且確定可能會拋出錯誤的
utility function
把 fetch 重新封裝
把 fetch 重新封裝
⽤ axios 更⽅便 請求失敗 回應失敗 axios: Interceptors 圖片來源:Flaticon.com、 WIKIPEDIA
window.onerror 呢? Sentry 會幫我們⾃動捕獲所有的 uncaught error 除非你對 uncaught error 需要做其他的錯誤處理,不然你不會需要⽤到。
圖片來源:Flaticon.com
最後的⼀些⼩建議 • 並不是所有專案都需要做錯誤監控,也不需要⼀次做到位 • 如果有專案有整合錯誤監控系統要好好善⽤ • 注意不要將使⽤者的機密資訊傳到錯誤監控系統 • 容錯能⼒的「粒度」不⼀定要這麼細
Q & A yu2001 @justYu2001 圖片來源:Discord、 WIKIPEDIA
None