Chienlung's Blog

Sentry Issue 匯出工具

Mon, 06 Oct 2025 15:19:37 +0800

週末期間用 Claude Code vibe coding 了一套可以將 Sentry issue 匯出成純文字的工具：export-sentry-issue，採 MIT 授權，同步發佈到 PyPI，順便做了 MCP 串接。只要告訴 Claude 你想要請他 review Sentry issue #編號，他就會自動幫你下載及分析 Sentry issue，加速除錯，相當方便。

隨著 AI 工具的日益成熟，從一開始只使用網頁版問答、到使用命令列工具直接的參與程式碼修改，工程師的角色已從 coder 變成 reviewer。在審查程式碼的過程中，可以發現新的問題，也可以學到新的知識。AI 不僅僅是協助完成工作，也可以協助思考。在 Docker 之後，我認為 AI Programming Assistant 已是工程師必備技能之一。

[AI 中文摘要] On | No syntactic support for error handling

Wed, 04 Jun 2025 11:04:35 +0800

本文為 AI 中文摘要，原始文章：[ On | No ] syntactic support for error handling - The Go Programming Language

文章摘要：Go 語言錯誤處理語法支援的探討與結論

日期： 2025年6月3日
作者： Robert Griesemer

1. 前言：Go 語言錯誤處理的冗餘性問題

Go 語言中常見的錯誤處理模式，即 if err != nil 檢查，長期以來因其冗餘 (verbosity) 而備受詬病。在大量進行 API 呼叫或錯誤處理相對單純（僅向上回傳）的程式中，此模式會淹沒主要邏輯程式碼。例如，一個簡單的 printSum 函數，其十行程式碼中，有六行專用於錯誤檢查與回傳，僅四行執行實際運算。此問題在年度使用者調查中持續名列前茅（僅次於泛型 (generics) 問題，在泛型支援後重回首位）。Go 團隊對此高度重視，並多年來持續尋求解決方案。

2. Go 團隊在錯誤處理語法上的歷史性嘗試

Go 團隊針對錯誤處理的冗餘問題，進行了多次重要的語法改進嘗試：

2.1. check 與 handle 機制 (2018年)

由 Russ Cox 正式提出，基於 Marcel van Lohuizen 的草案設計。
該機制引入了 check 關鍵字用於檢查錯誤，handle 區塊用於定義錯誤處理邏輯。

範例：

func printSum(a, b string) error {
    handle err { return err } // 定義錯誤處理方式
    x := check strconv.Atoi(a) // 若 strconv.Atoi(a) 回傳錯誤，則執行 handle 區塊
    y := check strconv.Atoi(b) // 同上
    fmt.Println("result:", x + y)
    return nil
}

此提案因被認為過於複雜而未被採納。

2.2. try 內建函數提案 (2019年)
- 作為 check/handle 的簡化版，try 是一個內建函數 (built-in function)，若其參數表達式回傳錯誤，try 會使當前函數立即回傳該錯誤。
- 為評估影響，團隊開發了 tryhard 工具將現有程式碼轉換為使用 try。
- 範例：
```
func printSum(a, b string) error {
    x := try(strconv.Atoi(a)) // 若 strconv.Atoi(a) 回傳錯誤，printSum 將回傳該錯誤
    y := try(strconv.Atoi(b)) // 同上
    fmt.Println("result:", x + y)
    return nil
}
```
- 此提案因其隱含的控制流程 (control flow) 改變（可能從深層巢狀表達式中提前返回）而引發爭議，最終被放棄。
- 事後反思，引入新關鍵字而非內建函數，並限制其使用範圍，或許是更佳的途徑。
2.3. ? 運算子提案 (2024年)
- 由 Ian Lance Taylor 提出，借鏡 Rust 語言的 ? 運算子。
- 期望藉由參考已建立的機制與符號來取得進展。
- 非正式使用者研究顯示，多數開發者能正確理解 ? 的含義。
- 團隊開發了轉換工具並在編譯器中原型化了此功能。
- 範例：
```
func printSum(a, b string) error {
    x := strconv.Atoi(a) ? // 若 strconv.Atoi(a) 回傳錯誤，printSum 將回傳該錯誤
    y := strconv.Atoi(b) ? // 同上
    fmt.Println("result:", x + y)
    return nil
}
```
- 此提案同樣迅速引發大量討論與基於個人偏好的微調建議，未能獲得廣泛支持，最終提案被關閉並轉為討論。

3. 社群的持續參與及提案過程的反思

在 Go 團隊嘗試的同時，社群也湧現了大量錯誤處理提案（數以百計），多數為既有概念的變體。Ian Lance Taylor 為此創建了追蹤議題 (umbrella issue) 及 Go Wiki 頁面以彙整相關資訊。

try 提案的失敗促使團隊反思提案流程，Russ Cox 的系列部落格文章指出，過早提出近乎完整的提案並設定緊迫的實施時程，可能減少了社群反饋的空間，影響了結果。

4. Go 團隊的最終決定：暫停追求語法層面的解決方案

歷經多年、多次官方及大量社群提案均未能達成共識後，Go 團隊決定：

在可預見的未來，停止追求針對錯誤處理的語法層級語言變更 (syntactic language changes)。
關閉所有主要涉及錯誤處理語法的現有及未來提案，不再進一步調查。

此決定的依據是 Go 的提案流程 (proposal process) 要求達成普遍共識 (general consensus)，而所有錯誤處理提案均未達到此標準。即使是 Go 團隊資深成員內部，目前也未對最佳方案有一致看法。

5. 維持現狀 (Status Quo) 的論點

支持維持當前錯誤處理方式的論點包括：

時機已過： Go 已發展15年，儘管冗餘，但現有的錯誤處理方式運作良好。若早期引入語法糖 (syntactic sugar)，爭議可能較小。
避免新的分歧： 引入新語法會使一部分偏好現狀的使用者不滿。
與泛型的差異： 泛型是可選的，而新的錯誤處理語法幾乎會要求所有人都採用，以維持程式碼的慣用風格 (idiomatic)。
Go 設計原則： 避免為同一件事提供多種做法。
- 諷刺的是，短變數宣告 (short variable declarations) := 中的變數重宣告 (redeclaration) 功能，部分是為了解決錯誤檢查序列中 err 變數命名問題而引入。若有更好的錯誤處理語法，此規則或可避免。

實際錯誤處理的影響： 當錯誤被「實際處理」（例如，使用 fmt.Errorf 添加上下文信息）時，樣板程式碼 (boilerplate) 的相對比例會降低。

範例：

func printSum(a, b string) error {
    x, err := strconv.Atoi(a)
    if err != nil {
        return fmt.Errorf("invalid integer: %q", a) // 錯誤被包裝
    }
    // ...
}

標準庫的輔助： 新的標準庫功能（如 cmp.Or）可以幫助減少樣板。

範例：

func printSum(a, b string) error {
    x, err1 := strconv.Atoi(a)
    y, err2 := strconv.Atoi(b)
    if err := cmp.Or(err1, err2); err != nil { // 一次處理多個錯誤
        return err
    }
    // ...
}

工具的輔助：
- 撰寫： IDE 和 LLM 輔助的程式碼完成 (code completion) 可簡化重複錯誤檢查的撰寫。
- 閱讀： IDE 或可提供開關以隱藏錯誤處理程式碼。
- 除錯 (Debugging)： 明確的 if 陳述式更易於設定中斷點 (breakpoint) 或添加調試輸出，而隱藏在 check、try 或 ? 後的邏輯則需先轉換回 if 形式。
實際成本考量： 語言變更成本高昂（設計、實施、文件更新、工具調整），而 Go 團隊資源有限，尚有其他優先事項。
部分使用者反饋： 在 Google Cloud Next 2025 等場合，部分 Go 使用者明確表示不希望改變現有錯誤處理方式，並認為隨着對 Go 的熟練度增加，此問題的重要性會降低。

6. 支持變革的論點（雖未被採納）

儘管決定不進行語法變更，但支持變革的論點依然存在：

使用者調查中，錯誤處理冗餘仍是首要抱怨。
關注點或許不應僅是減少字元數，而是透過關鍵字等方式提高預設錯誤處理的可見性，進而提升程式碼品質與安全性。
目前尚不完全清楚問題的核心是語法冗餘，還是良好錯誤處理（建構對開發者和終端使用者都有意義的錯誤）本身的複雜性。

7. 結論與未來展望

鑑於對問題本身及其是否存在缺乏共識，Go 團隊做出務實決定：在可預見的未來停止追求錯誤處理的語法層級語言變更。團隊感謝社群在探討此議題上的巨大投入，這些努力雖未直接改變錯誤處理語法，但也促成了 Go 語言及流程上的其他改進。團隊期望將這份熱情投入到新的機會，使 Go 對所有人更好，並期待未來或許會對錯誤處理問題有更清晰的認識。

修復 iPhone SE2 白屏死機畫面

Sun, 28 Apr 2024 00:08:44 +0800

iPhone SE2 (iOS 17.4.1) 不明原因出現白屏死機畫面，嘗試過按住側邊按鈕、同時按住側邊按鈕及主畫面按鈕都沒辦法叫出關機滑桿。照著 Apple 官方教學執行以下步驟，結果有用，成功救了一台 iPhone。

按下調高音量按鈕後迅速放開。

按下調低音量按鈕後迅速放開。

按住側邊按鈕，直到看到 Apple 標誌為止（大約 10 秒鐘）。

這個方法有用但冷門，一般使用 PC 的習慣，直覺會想到按住一個按鈕或同時按住兩個按鈕。至於有的網站說可以下載修復工具之類的軟體，這倒是可以建議一個都不要嘗試。

Firefox 的 Caret Browsing

Sat, 20 Apr 2024 06:11:31 +0800

最近發現瀏覽 Firefox 頁面時，滑鼠點擊頁面的任何位置都會出現游標，本來以為是某個更新版本出現的 bug，但覺得也過太久沒有修正了。於是搜尋是否有人回報這個問題，找到這篇，原來是我不小心啟動了文字游標瀏覽 (Caret Browsing) 功能。該功能的熱鍵是 F7，點擊 F7 之後就可以關閉這項功能。

Caret Browsing 是無障礙功能之一，目的是使用鍵盤操作，但我覺得沒有很好用。純鍵盤瀏覽網頁，我會推薦使用 Vimium 擴充套件。

解決 rb-inotify 的 Permission Denied 錯誤

Fri, 12 Apr 2024 07:36:35 +0800

在開發 Ruby on Rails 網站時，使用 rails g controller 指令新增 controller 時，出現一個錯誤：

/home/**/.rbenv/versions/2.6.10/lib/ruby/gems/2.6.0/gems/rb-inotify-0.10.1/lib/rb-inotify/notifier.rb:200:in `initialize': Permission denied @ dir_initialize - /home/**/**/srv/pg (Errno::EACCES)

原因是 rb-inotify 掃描專案根目錄下的 srv/pg 資料夾時遇到存取權限問題。該資料夾是用 PostgreSQL docker container 建立的，只有 root 才有讀取權限。

我想知道能不能設定 rb-inotify ，將 srv/pg 加入例外清單，但發現無法，且作者似乎也不打算處理 ^[1]^[2]。最後找到解法，在 config/sprint.rb 原本的內容上方加入以下程式碼，改寫原本的 watch 方法：

INOTIFY_BLACKLIST = [
  ".git",
  "node_modules",
  "tmp",
  "log",
  "srv"
].map { |dir| Pathname(Spring.watcher.root).glob(dir) }.flatten.map(&:to_s)

require "rb-inotify"
module INotifyNotifierIgnorer
  def watch(path, *flags, &callback)
    return if INOTIFY_BLACKLIST.include?(path)

    # warn path # to see all the paths listened to
    super(path, *flags, &callback)
  end
end
INotify::Notifier.prepend INotifyNotifierIgnorer

Windows Terminal 支援 Font Fallback

Thu, 11 Apr 2024 01:13:16 +0800

最近在研究 Windows Terminal 有沒有什麼方法可以顯示自訂中文字型，但英文仍保留等寬字型 (monospace)。在 GitHub Issue 看到最近已經有人實作 font fallback 功能並合併到主分支裡面了，但尚未釋出到穩定版。要使用這功能，可以下載 Windows Terminal Canary，這是 Windows Terminal 的 Nightly build 版本。安裝後打開設定 JSON 檔案，找到 font ➔ face key，改成跟 CSS font-family 一樣的格式就可以。

{
  "font": {
    "face": "'DejaVuSansM Nerd Font Mono', 'Noto Sans CJK TC'"
  }
}

HSTS vs HTTPS-Only Mode

Wed, 06 Dec 2023 01:27:59 +0800

近年來主流的瀏覽器陸續支援 HTTPS-Only Mode^[1]^[2]^[3]。該模式啟用時，使用者造訪任何網站，瀏覽器都會優先選用 HTTPS。

HTTP Strict Transport Security (HSTS) 是一個網路安全機制，透過伺服器的回應帶有 Strict-Transport-Security 標頭，強制瀏覽器只能使用 HTTPS 傳輸。

這兩者有何差別呢？ Mozilla Blog 有一篇文章^[4]的圖文解說相當清楚。簡單的說，HTTPS-Only Mode 可以確保使用者訪問網站送出的第一個請求是 HTTPS。當網站不支援 HTTPS 時，會跳出警告讓使用者選擇是否改以 HTTP 訪問。HSTS 的機制則是做到完全的禁止使用者以 HTTP 訪問，但前提是使用者必須先以 HTTPS 進行請求，才會收到 Strict-Transport-Security 標頭。HSTS 無法確保使用者訪問網站時送出的第一個請求為 HTTPS，首次連線很容易面臨中間人攻擊的風險。

Youtube RSS Finder

Tue, 07 Nov 2023 16:11:53 +0800

YouTube 頻道是我常用的 RSS 訂閱源之一，去年十月官方全面開放「@使用者」帳號的申請^[1]，隨著大多數人申請帳號，原本的頻道 ID (Channel ID) 就沒有出現在網址上面了。YouTube 頻道訂閱源網址的形式為 https://www.youtube.com/feeds/videos.xml?channel_id=<channel_id>，channel_id 可以直接的在頻道首頁點右鍵->檢視原始碼，搜尋「videos.xml」關鍵字找到，所以也不是什麼費工的事。

會做 YouTube RSS Finder，最主要的動機是為了學習 Vue3 和 Rust。多年前 React 的推行，其虛擬 DOM 的概念為前端帶來變革，那時就用 React 寫了 bookpocket 的 Chrome 擴充功能。當時有在使用 Pocket，它是一種網路書籤服務，可以將網頁加進書籤管理，以便稍後閱讀或分享等。官方的擴充功能無法顯示當前網頁是否已加入書籤，如果每次都要加入的話也挺麻煩，因此利用 Pocket API 做成擴充功能，未加入的網頁，其網址列顯示藍色圖示，已加入則顯示紅色圖示。

至於為什麼要學前端？只做後端雖然可以做命令列介面 (CLI) 軟體，但會操作這類介面的使用者通常都要有一點工程背景。如果有什麼想法想面向一般大眾，圖形介面 (GUI) 必不可少。想法與行動皆不受限，才有機會創造更多價值。

📣 Announcing YouTube handles: a unique identifier to discover and connect on YouTube - YouTube Community

Firefox 119.0 中文字型無法正常顯示

Tue, 31 Oct 2023 19:32:31 +0800

Firefox 更新到 119.0 之後，發現原本設定的自訂中文字型（像是思源黑體）無法正常顯示在網頁上。查閱了更新日誌，有一段寫著：

The visibility of fonts to websites has been restricted to system fonts and language pack fonts in Enhanced Tracking Protection strict mode to mitigate font fingerprinting.

Firefox 119.0 加入了字型指紋 (font fingerprinting)^[1] 保護機制，在加強型追蹤保護的嚴格模式下，只允許渲染作業系統內建及語言包的字型。

要解決這個問題，可以改成自訂模式，將「疑似是數位指紋追蹤程式」限定於隱私瀏覽視窗或取消選取^[2]。

我的待辦工具遷移史

Mon, 16 Oct 2023 18:58:47 +0800

Wunderlsit (奇妙清單) 待辦工具於 2015 年被微軟收購（後被關閉），四年後創辦人 Christian Reber 反悔，表示想把產品買回來^[1]，豈料未果。他於 2020 年另起爐灶，創立了競品 Superlist^[2]，如今已漸成熟，我在上週三收到了 Private Beta 測試邀請。

我的待辦工具軟體，最早是用 Emacs Org Mode 搭配 Google Drive 同步功能，當智慧型手機慢慢流行以後，對於沒有好用的行動版應用程式相當不太方便，尤其是通知功能；加上 Windows 也要安裝 Emacs，Org Mode 對跨平台實在不太友善。

後來改用 Google Tasks，這款應用綁在 Gmail 介面下，在側邊欄就可以操作，相當方便。漸漸我不再以 Gmail 作為主要 Email 產品，Google Tasks 也沒有獨立的 Web 介面^[3]，於是再尋找其他的替代品。

思考良久，一款符合我期待的待辦工具應用，必須符合以下條件：

跨平台 (Windows / macOS / iOS)
To-Do 功能導向，非筆記
尊重隱私，最好符合 GDPR
不 Lag 的使用操作體驗
支援資料匯出（可以離線儲存更好）
支援上傳附件
多時段通知功能
重複建立功能（當任務勾選完成後，自動建立重複任務）
支援 Share Extension
支援 iCalendar（方便整合到行事曆）
良好的客服信譽

Self-Hosted Open Source 是我的首選，然而調查了一輪，沒有找到我滿意的應用程式。

接著找到 Todoist，覺得滿意，也使用了好幾年。某天我發現一個清單包含 300 個以上（未完成）任務時，會極度 Lag（早期我還把它當作網頁 read later 在用），影響使用體驗。Wunderlist 是跟 Todoist 介面最為相近的軟體，轉到 Wunderlist 沒多久就傳來被微軟收購的消息，心得不多。

最後使用 TickTick。TickTick 後來出了一個我不太喜歡的功能，該功能會自動的將標題內的網址轉換為 Markdown 格式的網站標題及連結，問題在於有些網址需要登入權限或有阻擋爬蟲，標題會變成「系統異常回報」或「需登入」之類的文字，無法根據標題判斷為不同的待辦事項。該功能也不能 opt-out。寫信建議客服也僅得到了我們會考慮的回覆。

TickTick 不是我的終點，Superlist 仍在觀望，期待未來可以脫胎換骨。

修復 Windows 檔案總管預覽 PDF 出錯

Mon, 12 Sep 2022 18:38:23 +0800

今天 Adobe Acrobat Reader 在檔案總管預覽 PDF 時出現了不明的錯誤。

因為想要測試 Adobe 軟體能不能在 Sandboxie 沙盒內正常運作，故解除安裝原本裝好的 Adobe Creative Cloud，也連帶解除安裝 Acrobat Reader DC。當測試完 (並且失敗) 裝回 Acrobat Reader，發現在檔案總管點選 PDF 檔案，游標持續呈現沙漏（卡頓）。十數秒後，出現上圖的錯誤，猜測是預覽窗格造成的問題。

嘗試過用 Creative Cloud Cleaner Tool^[1] 和 AcroCleaner^[2]，希望能將 Adobe 軟體徹底從系統清除，再重安裝，看看有沒有修復。

結果失敗了。

Acrobat Reader 的偏好設定裡面，「啟用 Windows 檔案總管中的 PDF 縮圖預覽」選取後會安裝新的模組，這項功能就算啟用，依然會出現錯誤。

後來我看到這一篇文章，提到可以透過修改機碼來改變檔案總管的 PreviewHandler。最終我將 PDF PreviewHandler 換成微軟自家的，算是解決了這個問題，而且預覽窗格渲染的速度也變得相當快。

從 \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\PreviewHandlers 可以看到機碼為 {DC6EFB56-9CFA-464D-8880-44885D7DC193} 的是 Acrobat Reader 的預覽處理常式。

而 {3A84F9C2-6164-485C-A7D9-4B27F8AC009E} 則是 Microsoft PDF Previewer。
到 \HKEY_CLASSES_ROOT\.pdf\ShellEx\{8895b1c6-b41f-4c1c-a562-0d564250836f} 底下打開名為 (預設值) 的機碼，將數值改成 {3A84F9C2-6164-485C-A7D9-4B27F8AC009E}，就完成了。

在路由器安裝 OpenWrt 及 WireGuard VPN

Mon, 12 Sep 2022 00:13:54 +0800

最近買了一台空氣清淨機，附有 Wifi 功能，可以隨時透過 App 偵測室內空氣品質。我覺得這點做得滿棒的，但因為數據是直接傳到廠商的伺服器，想把對外的 IP 隱藏起來，興起了想透過路由器設定 VPN 的念頭。

原本相中 PCWRT 家的路由器，但正逢缺貨，作為替代找了一款便宜的迷你型路由器 GL.iNet GL-MT300N，用的是聯發科晶片，可以安裝 OpenWrt 系統。

以下簡要敘述安裝的過程。

到 OpenWrt 官網下載預先編譯好的韌體。
將路由器接上電源、連上 Wifi 後，進入 http://192.168.8.1，上傳並安裝 OpenWrt 韌體檔。
安裝後，透過 LAN 連線，確定連線並取得 DHCP IP，進入 http://192.168.1.1，預設帳號及密碼皆為 root。
到 System ➔ Software，點擊 Update lists... 按鈕，等待系統更新 package 列表。Filter 搜尋 wireguard，找到 luci-app-wireguard 並安裝。安裝完到 System ➔ Reboot 重啟系統。
到 Network ➔ Interfaces 新增 WireGuard 介面，名稱隨意訂，Protocol 選 WireGuard VPN，點建立。
編輯 WireGuard 介面，透過最下方的 Import configuration 匯入從 ProtonVPN 網站生成的 WireGuard config 檔。
編輯 WAN 介面，切換到 Advanced Settings 分頁，取消勾選 Use DNS servers advertised by peer，然後在 Use custom DNS servers 填入 ProtonVPN config 檔所提供的 DNS server 位址。
到 Network ➔ Firewall 新增 Zone，名稱隨意取，Input 選 rejected、Output 選 accepted、Forward 選 rejected，Masquerading 和 MSS clamping 都勾選；Covered networks 選剛剛建立的 WireGuard 介面；Allow forward from source zones 選 lan 介面。
如果想要在 VPN 連不上的時候斷開網路，不要改連 WAN，就要設定 Kill Switch。編輯 lan zone，從 Allow forward to destination zones 移除 WAN 介面，只留下 WireGuard 介面。
至此就設定完成了。可以在連線 LAN 後檢查 WireGuard 介面的 RX 跟 TX 有沒有收到封包，若有代表有成功透過 WireGuard 介面傳輸。