【開發智能合約 — Solidity系列】實作篇Ep.5 - 錯誤處理的機制(Error Handling)

更新於 發佈於 閱讀時間約 6 分鐘
Solidity語言的錯誤檢查提供了Require()、Revert()、Assert(),這三種方便的API調用,而這三種用途分別不同,畢竟牽涉到瓦斯費的問題,因此才會與過往的程式語言有些許的差異,

Require

require()通常會被使用在輸入值的驗證檢查,因為它的特性主要是能夠退回剩餘的Gas fee,我們也知道瓦斯費在區塊鏈的成本是昂貴的,因此這些檢查都有助於不必要的浪費,主要使用方式為:
require(判斷式, 訊息)
...
contract Example {
... function withdraw(uint amount) public pure {
uint total = 100;
/// @dev 提款的數量必須低於總額度
/// @notice 使用require(), 當條件不滿足時將退回剩下的瓦斯費,所以通常會放在前面
require(amount <= total, "amount must less then total"); ...
}
}

Revert

revert()顧名思義為撤銷的意思,也就是通常不符合某些條件時則進行撤銷,與reqiure一樣是會退回剩餘的Gas fee,那看到這邊可能心裡會產生一些疑問,比如說為什麼不用require就好了呢? 兩者語意事實上是有差異的。
  • require表述的是「必須要滿足什麼條件」。
  • revert則表述「當什麼條件未被滿足」時進行撤回。
/// @dev 自訂錯誤類型: 資金不足
/// @param requested 要求的資金
/// @param available 可用的資金
error NotEnoughFunds(uint requested, uint available);function ... {
/// @dev 提款的金額不能大於存款
/// @notice 若提出的金額超過存款總額,則退回撤銷並退回狀態。
if (amount > total) {
revert NotEnoughFunds(amount, total);
}
}
另外revert使用的方式有以下三種:
  • revert CustomError(…)
  • revert(”message”)
  • revert()
剛開始可能會有些霧裡看花,這麼多不同的承接方式與參數,但撰寫一段時間過後就會相當熟練,且在合適的時機使用正確的方式。

Assert

assert()跟require()一樣,算是進行檢核的機制,必須滿足某些條件才能繼續執行,但最大的差異在於當條件不滿足時,會耗盡Gas fee,因此通常用來處理比較嚴重且不易發生的錯誤,例如邊界值、特殊條件…等程式內部錯誤,也是最不常被使用的錯誤處理方法。
/// @dev 提款的額度必須是正整數
assert(amount > 0);

Try … Catch

相信這種語法如果有在開發其他程式的朋友應該非常熟悉,沒錯,Solidity亦提供這種錯誤處理機制,但值得注意的是在智能合約的世界中僅適合外部調用,白話來說就是A合約去嘗試使用B合約的功能,語法結構主要為:
try ...使用A合約進行什麼操作 {
...成功之後的處理
} catch ...什麼類型的錯誤 {
...進行什麼處理
} catch ...什麼類型的錯誤 {
...進行什麼處理
}
而錯誤的捕捉類型又分為以下四種方式,分別說明:
contract Example {
...
}contract Runner {
Example public example; constructor() {
example = new Example();
} function exec() public view {
uint errorCount = 0;
try example.withdraw(101) {
// 提款成功之後...
} catch Error(string memory /*reason*/) {
// 這種錯誤類型主要是處理帶有錯誤訊息的錯誤處理函數: require(..., "錯誤訊息")、revert("撤銷訊息")
errorCount++;
} catch Panic(uint /*errorCode*/) {
// 這種錯誤類型主要處理assert(...)這種內部錯誤
errorCount++;
} catch (bytes memory /*lowLevelData*/) {
// 這種錯誤通常發生在更低階的處理,像是在解譯(decode)的階段
errorCount++;
} catch {
// 如果不想知道錯誤訊息或者原因時,可以直接用catch { ... }進行錯誤的對應處理。
}
}
}

結語

原來一個簡單的錯誤處理背後其實並不簡單…,與「金錢」有關的產品或服務最重要的莫過於嚴謹的審查機制,因此很多錯誤都是不能被容忍的,故而錯誤處理的機制就顯得非常重要,處理方式也相較於大部分程式語言有所不同,主要是因為納入了Gas fee的緣故,以此為鑑,當開發者進行開發智能合約時的錯誤處理也要非常小心,哪個使用情境要用哪一種錯誤處理的技巧並且不浪費Gas fee的狀況下,真的是對於智能合約開發者來說是一大挑戰,相信我們只要讀懂這些錯誤處理的概念後,未來開發時就會特別注意。
今天的範例都在這裡「📦 solidity-remix-toturial/Ep5」歡迎自行取用。

資源參考

為什麼會看到廣告
avatar-img
119會員
268內容數
哈囉,我是阿Han,是一位 👩‍💻 軟體研發工程師,喜歡閱讀、學習、撰寫文章及教學,擅長以圖代文,化繁為簡,除了幫助自己釐清思路之外,也希望藉由圖解的方式幫助大家共同學習,甚至手把手帶您設計出高品質的軟體產品。
留言0
查看全部
avatar-img
發表第一個留言支持創作者!
阿Han的沙龍 的其他內容
每個產品在實驗室研發出來後,勢必會面臨到賣給客戶的階段,那麼當我們將產品移交給客戶時,意味著也要進行環境的安裝,但問題來了,每一個客戶的環境差異甚大,總不可能為了A客戶就建立一個A客戶的環境,因應B客戶就建立B客戶的環境,這樣隨著產品的銷售量增長也將連帶耗盡公司的資源,想必這不是我們所樂見的現象,當
建議閱讀前可以先了解一下「【開發智能合約 — Solidity系列】開發環境準備」,會比較容易操作Remix來開發智能合約。 Remix IDE的Debug方式其實也類似於我們開發軟體程式過程中的Debug流程,編輯好程式碼之後,經過編譯,發佈到暫存鏈上,對每一個區塊進行Debug,過程中逐步排查出
「人」與「人」之間無非時時刻刻都在交易,只是每一種交易的形式與媒介有所不同,而區塊鏈的世界也有特定的交易單位,主要分為兩大類型的單位, 分別是以乙太幣單位以及時間單位。 最小單位為「wei」, 而其餘主要會用到的單位分別是「gwei」與「ether」。 時間單位的部份就比較容易理解了, 非常直觀,
資料型態在合約當中扮演著什麼角色呢? 我們在「【開發智能合約 — Solidity系列】實作篇Ep.2 — 合約中的基本組成元素」有介紹過狀態變數可以儲存一些變化值,而儲存什麼類型的值就是所謂的資料型態,不同的資料型態可以處理的事物也有所不同,因此我們也需要了解一些基本的資料型態以及特性之後,未來開
每個產品在實驗室研發出來後,勢必會面臨到賣給客戶的階段,那麼當我們將產品移交給客戶時,意味著也要進行環境的安裝,但問題來了,每一個客戶的環境差異甚大,總不可能為了A客戶就建立一個A客戶的環境,因應B客戶就建立B客戶的環境,這樣隨著產品的銷售量增長也將連帶耗盡公司的資源,想必這不是我們所樂見的現象,當
建議閱讀前可以先了解一下「【開發智能合約 — Solidity系列】開發環境準備」,會比較容易操作Remix來開發智能合約。 Remix IDE的Debug方式其實也類似於我們開發軟體程式過程中的Debug流程,編輯好程式碼之後,經過編譯,發佈到暫存鏈上,對每一個區塊進行Debug,過程中逐步排查出
「人」與「人」之間無非時時刻刻都在交易,只是每一種交易的形式與媒介有所不同,而區塊鏈的世界也有特定的交易單位,主要分為兩大類型的單位, 分別是以乙太幣單位以及時間單位。 最小單位為「wei」, 而其餘主要會用到的單位分別是「gwei」與「ether」。 時間單位的部份就比較容易理解了, 非常直觀,
資料型態在合約當中扮演著什麼角色呢? 我們在「【開發智能合約 — Solidity系列】實作篇Ep.2 — 合約中的基本組成元素」有介紹過狀態變數可以儲存一些變化值,而儲存什麼類型的值就是所謂的資料型態,不同的資料型態可以處理的事物也有所不同,因此我們也需要了解一些基本的資料型態以及特性之後,未來開
你可能也想看
Google News 追蹤
Thumbnail
嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
Thumbnail
違約金是在公司交易中常見的一部分,但當收到違約金時,是否需要開立發票呢?這篇文章針對違約金的帳務及稅務處理進行了詳細介紹,並提供了具體的案例分析,幫助大家更好的瞭解違約金。如果您正在尋找違約金相關的資訊,這篇文章在帳務及稅務處理的角度為您提供了一個清晰的解釋。
Thumbnail
本章節旨在介紹Java程式語言中的「例外處理」概念。透過各個小節,讀者將學習到何謂例外處理、為何要使用它、如何在Java中實現例外處理,以及如何正確地捕獲和處理各種類型的異常。此外,本章節還提供了如何主動觸發異常,以及如何創建和使用自定義異常的實例。
Thumbnail
這篇文章主要講解Kotlin的例外處理。內容包括例外處理的目的、`try-catch` 和 `finally` 的用法、常見的異常類型,以及如何定義和觸發自定義的異常訊息。
Thumbnail
本章節為Swift程式語言的異常處理介紹,說明了為何需要進行異常處理以及如何進行異常處理。提供了使用do、try、catch和throw關鍵字進行異常處理的基本語法並展示了其在實際程式中的應用。同時也說明了Swift中的一些常見異常類型,並且教導了如何主動觸發異常訊息和定義自己的異常類型。
Thumbnail
本章節的目的是介紹在TypeScript中如何進行例外處理。涵蓋了例外處理的重要性、語法、常見異常類型以及如何主動觸發異常訊息及用戶自定義異常訊息。為讀者提供了全面而深入的了解,以提高程式的可靠性、提供更好的反饋、增加程式的容錯性以及改善程式的可讀性。
Thumbnail
當你在開發程式時,難免會遇到各種錯誤和異常情況。這些錯誤可能是因為代碼中的錯誤、外部資源無法訪問或其他不可預期的狀況。為了提高程式的可靠性、穩定性和可維護性,我們使用「例外處理」來處理這些異常情況。
Thumbnail
本章節介紹C#的「例外處理」,包括使用try-catch語法處理錯誤,finally關鍵字的使用,以及如何主動引發和自定義異常。
Thumbnail
例外處理是Python中的重要概念,用於控制並處理程序異常,防止程序崩潰和數據損失。它包括try, except, else和finally等語法結構,可用於對特定錯誤進行處理,或主動觸發和自定義異常。
Thumbnail
口頭契約很容易說出口... 雙方的認知承諾也可能因理解有誤差... 沒有再三確認,誤解可能由此而生~ 生意場上~即使是甲方的要求,乙方也無需照單全收~ 畢竟許多的要求都來自於利益的堆疊! 當雙方並非站在對等的平台上協商,誤知誤解就隨之而生... 無論是哪一種狀況...都不要讓自己賠掉~
Thumbnail
嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
Thumbnail
違約金是在公司交易中常見的一部分,但當收到違約金時,是否需要開立發票呢?這篇文章針對違約金的帳務及稅務處理進行了詳細介紹,並提供了具體的案例分析,幫助大家更好的瞭解違約金。如果您正在尋找違約金相關的資訊,這篇文章在帳務及稅務處理的角度為您提供了一個清晰的解釋。
Thumbnail
本章節旨在介紹Java程式語言中的「例外處理」概念。透過各個小節,讀者將學習到何謂例外處理、為何要使用它、如何在Java中實現例外處理,以及如何正確地捕獲和處理各種類型的異常。此外,本章節還提供了如何主動觸發異常,以及如何創建和使用自定義異常的實例。
Thumbnail
這篇文章主要講解Kotlin的例外處理。內容包括例外處理的目的、`try-catch` 和 `finally` 的用法、常見的異常類型,以及如何定義和觸發自定義的異常訊息。
Thumbnail
本章節為Swift程式語言的異常處理介紹,說明了為何需要進行異常處理以及如何進行異常處理。提供了使用do、try、catch和throw關鍵字進行異常處理的基本語法並展示了其在實際程式中的應用。同時也說明了Swift中的一些常見異常類型,並且教導了如何主動觸發異常訊息和定義自己的異常類型。
Thumbnail
本章節的目的是介紹在TypeScript中如何進行例外處理。涵蓋了例外處理的重要性、語法、常見異常類型以及如何主動觸發異常訊息及用戶自定義異常訊息。為讀者提供了全面而深入的了解,以提高程式的可靠性、提供更好的反饋、增加程式的容錯性以及改善程式的可讀性。
Thumbnail
當你在開發程式時,難免會遇到各種錯誤和異常情況。這些錯誤可能是因為代碼中的錯誤、外部資源無法訪問或其他不可預期的狀況。為了提高程式的可靠性、穩定性和可維護性,我們使用「例外處理」來處理這些異常情況。
Thumbnail
本章節介紹C#的「例外處理」,包括使用try-catch語法處理錯誤,finally關鍵字的使用,以及如何主動引發和自定義異常。
Thumbnail
例外處理是Python中的重要概念,用於控制並處理程序異常,防止程序崩潰和數據損失。它包括try, except, else和finally等語法結構,可用於對特定錯誤進行處理,或主動觸發和自定義異常。
Thumbnail
口頭契約很容易說出口... 雙方的認知承諾也可能因理解有誤差... 沒有再三確認,誤解可能由此而生~ 生意場上~即使是甲方的要求,乙方也無需照單全收~ 畢竟許多的要求都來自於利益的堆疊! 當雙方並非站在對等的平台上協商,誤知誤解就隨之而生... 無論是哪一種狀況...都不要讓自己賠掉~