中毒中的包裝/功能

Question

TLDR：golang中是否有辦法（即使它有點不標準），「毒化」功能或完全導入某個包裝。

更長的版本：我正在編寫一個節儉服務，所有面向公共職能的函數都返回結果，或者在thrift文件中聲明的某種類型的錯誤。該代碼生成器，這樣的界面生成代碼：

publicFacingFunc(...) (returnType, error) 

這將是巨大的，直到有人我一起工作決定檢查其他疾病時，以及當條件不滿足做這樣的事情：

if conditionIsNotMet { 
    return nil, errors.New(...) 
} 

代碼編譯，但是當錯誤出現時，收到的消息是無證的隨機字符串。所以在這些文件中，我想阻止使用「錯誤」和「fmt」包。

是的，我試過了，仍然在文件頂部發出了一個警告，但似乎沒有人讀過。

順便說一句，公共錯誤都有各自的「構造函數」，這是這些文件的外部，只有那些應該使用，在我的情況。

Answer 1

如果你只關心一個文件中的包的使用，你可以用一個愚蠢的名字來導入它，比如'永遠'......人們可以使用它，但他們會明白我的想法。

import (
     NEVER "fmt" 
) 

，或者，如果你想少傻了，你可以使用_下劃線，https://golang.org/doc/effective_go.html#blank_import

import (
    _ "fmt" 
) 

將加載進口，但只有它的副作用（即不明確使用。

---

要停止不是某種類型的所有錯誤的輸入，你可以使用reflect爲了與類型斷言停止不良的類型，https://golang.org/ref/spec#Type_assertions

v, ok = x.(T) 

所以如果一個err在面向公衆的功能出現時，你不想通過，檢查它是什麼樣的錯誤，

specialError, ok := err.(mypackage.ErrorType) 
    if !ok { 
     // don't send this error on 
    } 

Answer 2

如果你真的要強制執行它可以執行構建步驟，檢查所有包的輸出go list，並確保fmt和errors不在直接導入列表中。儘管有這些常見的軟件包，但可能難以完全避免。你可以做更詳細的解析來檢測fmt.Errorf或其他什麼，但可能會很棘手。

更具侵略性的解決方案是修改這些軟件包的軟件包源代碼，並迫使開發者使用您的自定義分發版。對於在std庫中隨處可用的fmt和errors軟件包來說可能太難了，但它可能適用於其他軟件包。我絕不會推薦它。絕對可以將它作爲在簽入和PR和事物上運行的構建時驗證來添加。