摘要:近日在工作中由于疏忽問題導(dǎo)致某個客戶的系統(tǒng)直接崩盤,極大的影響了用戶使用產(chǎn)品的體驗(yàn)。在經(jīng)過修改之后,不得不思考下在日常開發(fā)中的一些壞習(xí)慣以及如何規(guī)避這些日常問題了。同時由于我們未能對錯誤進(jìn)行好的處理,導(dǎo)致程序直接卡死。
近日在工作中由于疏忽問題導(dǎo)致某個客戶的系統(tǒng)直接崩盤,極大的影響了用戶使用產(chǎn)品的體驗(yàn)。在經(jīng)過修改之后,不得不思考下在日常開發(fā)中的一些壞習(xí)慣以及如何規(guī)避這些日常問題了。
在日常開發(fā)中,我們往往會有很多不好的習(xí)慣,寫出一些非常不健壯的代碼,導(dǎo)致由于數(shù)據(jù)和條件的多樣性,程序未能作出很好的預(yù)判。同時由于我們未能對錯誤進(jìn)行好的處理,導(dǎo)致程序直接卡死。雖然這些問題可能是非常“低級”的錯誤,但也是非常常見的錯誤,所以有必要拿出來說一說。
1.為鍵值匹配設(shè)定默認(rèn)值針對以下這種鍵值匹配,我們往往并不能對所有的可能進(jìn)行枚舉,建議對其設(shè)置通用的默認(rèn)值,也避免了在業(yè)務(wù)邏輯中進(jìn)行重復(fù)的處理。避免為匹配到正確的值而報錯。
const map = (obj, defaultValue) => { return new Proxy(obj, { get (target, key) { // 你可以在這里進(jìn)行其他處理 return Reflect.get(target, key, receiver) || defaultValue } }) } const typeValueMap = map({ a: { color: "red", desc: "紅色" }, b: { color: "blue", desc: "藍(lán)色" } }, { color: "ccc", desc: "灰色" }) const result = typeValueMap[type]2.當(dāng)css-modules不能正確匹配時,不直接throw
css-modules會針對未能匹配的樣式名,直接拋出問題,使整個模塊崩掉。在生產(chǎn)環(huán)境中,個人覺得這種做法可能過于激進(jìn)了,當(dāng)然官方也提供了handleNotFoundStyleName參數(shù),用于設(shè)置未匹配時,是直接throw, warn還是忽略。在此我們可以進(jìn)行統(tǒng)一的處理:
import cssmodules from "react-css-modules" export default (style, allowMutiple = false) => cssmodules(style, { allowMultiple, handleNotFoundStyleName: "log" })3.對未知的事件進(jìn)行try/catch
程序的執(zhí)行過程中,我們往往無法保證傳入的數(shù)據(jù)是我們想要的,因此我們需要對一些不能保證的過程進(jìn)行try/catch,防止程序卡死。這也是很基礎(chǔ)的一個內(nèi)容了,但是保持良好的代碼風(fēng)格還是很重要的!
let ret try { ret = JSON.parse(json) } catch (error) { // 錯誤處理,錯誤上報 }4.使用ErrorBoundary對錯誤進(jìn)行友好提示,保證其他模塊的可用性
類似try/catch,在react 16中也提供了對組件內(nèi)部異常進(jìn)行捕獲的機(jī)制。我們可以利用這個機(jī)制,對錯誤進(jìn)行友好的提示,避免整個程序卡死,保證其他模塊是可用的,同時可以進(jìn)行錯誤上報等操作。
export default class ErrorBoundary extends Component { state = { error: false } componentDidCatch(error, info) { const { onError = report, children, ...others } = this.props this.setState({ error: { error, info, prop: others } }) onError(error, info, others) } render() { const { error } = this.state if (error) { return5.及時進(jìn)行錯誤回傳,監(jiān)控平臺的穩(wěn)定性} return this.props.children } }
通過配合類似sentry這樣的平臺錯誤上報與收集,可以很方便的拿到用戶的錯誤信息,錯誤時的props等數(shù)據(jù),方便定位問題,拿到重要的反饋信息。
6.總結(jié)總的來說,很多情況下錯誤的誕生還是由于我們代碼的“不健壯”導(dǎo)致的,所以在使用其他方案進(jìn)行規(guī)避的同時,如何提升代碼質(zhì)量,保證代碼穩(wěn)定運(yùn)行,是我們需要不斷追求與提升的。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/95353.html
摘要:直到有一天你會碰到線上奇奇怪怪的問題,如線程執(zhí)行一個任務(wù)遲遲沒有返回,應(yīng)用假死。正好這次借助之前的一次生產(chǎn)問題來聊聊如何排查和解決問題。本地模擬上文介紹的是線程相關(guān)問題,現(xiàn)在來分析下內(nèi)存的問題。盡可能的減少多線程競爭鎖。 showImg(https://segmentfault.com/img/remote/1460000015568421?w=2048&h=1150); 前言 之前或...
摘要:排查異常日志,發(fā)現(xiàn)沒有該問題存在。測試功能正常,沒有重現(xiàn)線上問題。解決問題原因定位好了,剩下的就是如何解決了。兩個方案修改線上配置該上實(shí)施難度系數(shù)高,因?yàn)楣臼褂玫慕y(tǒng)一發(fā)布部署平臺,開發(fā)人員無服務(wù)器操作權(quán)限。 問題 XX系統(tǒng)中,一個用戶需要維護(hù)的項(xiàng)目數(shù)過多,填寫的任務(wù)數(shù)超多,產(chǎn)生了一次工時保存中,只有前面一部分的xx數(shù)據(jù)持久化到數(shù)據(jù)庫,后面的數(shù)據(jù)沒有保存。 圖1 showImg(htt...
摘要:排查異常日志,發(fā)現(xiàn)沒有該問題存在。測試功能正常,沒有重現(xiàn)線上問題。解決問題原因定位好了,剩下的就是如何解決了。兩個方案修改線上配置該上實(shí)施難度系數(shù)高,因?yàn)楣臼褂玫慕y(tǒng)一發(fā)布部署平臺,開發(fā)人員無服務(wù)器操作權(quán)限。 問題 XX系統(tǒng)中,一個用戶需要維護(hù)的項(xiàng)目數(shù)過多,填寫的任務(wù)數(shù)超多,產(chǎn)生了一次工時保存中,只有前面一部分的xx數(shù)據(jù)持久化到數(shù)據(jù)庫,后面的數(shù)據(jù)沒有保存。 圖1 showImg(htt...
摘要:排查異常日志,發(fā)現(xiàn)沒有該問題存在。測試功能正常,沒有重現(xiàn)線上問題。解決問題原因定位好了,剩下的就是如何解決了。兩個方案修改線上配置該上實(shí)施難度系數(shù)高,因?yàn)楣臼褂玫慕y(tǒng)一發(fā)布部署平臺,開發(fā)人員無服務(wù)器操作權(quán)限。 問題 XX系統(tǒng)中,一個用戶需要維護(hù)的項(xiàng)目數(shù)過多,填寫的任務(wù)數(shù)超多,產(chǎn)生了一次工時保存中,只有前面一部分的xx數(shù)據(jù)持久化到數(shù)據(jù)庫,后面的數(shù)據(jù)沒有保存。 圖1 showImg(htt...
摘要:由于的限制,無法替換被代理類已經(jīng)被載入的字節(jié)碼,只能生成并載入一個新的子類作為代理類,被代理類的字節(jié)碼依然存在于中。區(qū)別于前兩者,是一種靜態(tài)代理的實(shí)現(xiàn),即在編譯時或者載入類時直接修改被代理類文件的字節(jié)碼,而非運(yùn)行時實(shí)時生成代理。 現(xiàn)象描述 上周同事發(fā)現(xiàn)其基于mySql實(shí)現(xiàn)的分布式鎖的線上代碼存在問題,代碼簡化如下: @Controller class XService { @A...
閱讀 1956·2021-11-23 09:51
閱讀 1255·2019-08-30 15:55
閱讀 1626·2019-08-30 15:44
閱讀 773·2019-08-30 14:11
閱讀 1153·2019-08-30 14:10
閱讀 924·2019-08-30 13:52
閱讀 2642·2019-08-30 12:50
閱讀 626·2019-08-29 15:04