引用
月のリリースgolang1.13は、それがより重要な機能のいくつかをリストアップします。私たちは、ひとつずつ、新しいバージョンで導入された新機能をこれら3つの分野の在庫変更や改善ツールチェーンを言語を変更します。
言語の変更
より多くのリテラルおよびデジタル：最初として、1.13は、これら2つの事、主にのみ、導入、言語の変更は最小限で、GO2バージョンを移行し始めたものののでチームは、前方互換するバージョン1.xをコミットされている行きます改善されたパニック情報。
デジタルリテラル
リテラルデジタルは、すべてのような、あまりにも身近なものであり100、0.99、1.というように。
不思議なことに、しかし、1.13 golangのサポートのみリテラル10進数と16進数の数字の前に、他の言語で広くサポートされているバイナリとオクタルはサポートされませんでした。たとえば、次のコードはコンパイルできません。
fmt.Println(0b101)
fmt.Println(0o10)リテラル構文上のgo1.13が既にサポートでは次のことができます0bまたは0Bリテラルバイナリ数字を示し、接頭辞にする0oと0O進リテラルを示すために。2つの方法があってもよいことは注目に値するが、すべて小文字をデフォルトgofmtので、私は使用をお勧めします0bし、0o可能な統一されたスタイルとしてあなたのコードが同じくらいにします。
別の変更は、デジタルリテラル進浮動小数点サポートの導入です。
浮動小数点数は16進数フロート法とヘクスで表され、バイナリ値に対応する16進形式で浮動小数点数を意味しない、むしろ16進数の形で次のようにことに留意すべきです。
0X十六进制整数部分.十六进制小数部分p指数通常の浮動小数点リテラルを省略することができるように、前記整数と小数部分は、デフォルト値は、0の部分を省略しています。P +部分インデックスを省略することができない、2の指標値であるシンボルインデックスがあってもよいです。
次のように前回のp値の一部を想定し、浮動小数点の16進リテラルの最終結果は、pはインデックスBであり、最終的な値は次のとおりですa * 2^b。
10は2となる指標から計算実際には、E pで置換されている科学的表記法、のように見えます。摂取量は16あたり1であるため、また、それは0x0.1p00.1のように見えるが、それは1/16を表し、そして0x0.01p0それは1/16 1/16は、徴候はより直感的になり示されているが、習慣後に問題ありませんA。例えば、ポイントの場合：
バイナリと進リテラルは、より一般的に進がそれをフロートすることを、使用されていますか？答えは、より正確かつ均一な表現です。
0x0.1p00.0625の10進値を表し、0x0.01p00.00390625であり、それはのfloat32精度範囲を超えているので、浮動小数点進リテラル値は精度の制限された範囲内で、より正確に表現することができます。統一された表現は、自然に似たフォームを使用する方が喜んで、進数表現の習慣の開発を説明する必要がありません。
具体例としては、参照することができる、本明細書。
最後に、デジタルリテラルだけでなく、小さな改善のために、アンダースコアで区切られた数字の読みやすさを向上することが可能になりました。例えば：
fmt.Println(100000000)
fmt.Println(1_0000_0000)
fmt.Println(0xff_ff_ff)デリミタはどこでも現れるかもしれませんが、同様に0x、完全な記号などを下線に挿入することができないとみなし、中間、文字の数は、セパレータとの間に定義されていない等しくなければならないが、読みやすくするためにそれぞれの食餌前に従うことが好ましいです。 1で区切られた3つのまたは4桁の数字。
境界エラー完璧のうちインデックス
私は言語の変更として分類されるが、実際にそれが定義されている間、ランタイムの改善がより適切であると。
我々はすべて知っているように境界配列参照のgolangは0とスライスクロスボーダーは、次の例のように、パニックになると、許容されます。
package main
import "fmt"
func main() {
arr := [...]int{1,2,3,4,5}
for i := 0; i <= len(arr); i++ {
fmt.Println(arr[i])
}
}あなたがこのプログラムを実行する場合は、苦情以上受信します。
ここでの例では、簡単に問題を特定することができ、それは振り返ってみると非常に困難なコールスタック情報はありませんが、非常に簡単だったですが、あなたは非常に並行プログラムであるコールチェーン場合したり暗く、物事がトラブルに巻き込まれる、またはログとデバッグを頼ります最終的な分析には関係なく、多くのエネルギーを費やす必要がどのような問題を見つけていない、どちらかのシングルステップブレークポイントのデバッグに依存するノイズの多くを除外し、私たちはただ、なぜクロスボーダーまで、コアの問題を考えて、その後、光ステップは、我々だけでつながる、時々知っているかもしれませんクロスボーダーの値は、おおよそ残念ながらgolang1.13までコンテンツが含まれていない提供された情報をパニック、問題の原因を決定することができます。
今golangは、クロスボーダーの値をプリントアウトするためにつながる、それは間違いなく、炭素を送る雪、次のとおりです。
もちろん、パニックして、情報が完全で万能薬ではない、ユニットテストと厳格な仕事のバグを改善することは最高のショットです。
ツールチェーンの改善
言語の変更レベルgodocに加えて、プログラムに加えて、最大の変化は、まだまだモジュールに集中して、同じツールチェーン素晴らしいではありませんが、ありません。
golangは、共通モジュールの動作を制御するために、3つの環境変数に参加し、そして以下に別々に記載されています。
GOPROXY
実際には、この変数が導入に1.12で、デフォルト値に加算し、この時https://proxy.golang.org,directに設定した場合、二つの変数とその背後にあるの値をカンマで区切ったリストで、直接、プロキシ経由で直接接続しないことを意味これは、同じですオフ、その後、任意のバイナリパッケージをダウンロードしてください。
などのパッケージを取得するためのコマンドを、取りに行くときに一致するパッケージが見つからない場合は、左から右にターン表情で、それはエラーになります。
言いたいことが自然言うまでもないの利点プロキシ、それは国内のパッケージに妨げられることなくアクセスいくつかの家庭環境に開発者を得ることができないことができます。さらに重要なのは、デフォルトのプロキシが大きい保護とセキュリティのため、サードパーティ製のプログラムに比べて、公式およびメンテナンスです。
GOSUMDB
この変数は、オンラインgo.sumデータベースの公式管理で指定されたと実際に同等です。私たちは具体的な説明を見てみる前に、パッケージのどのgolangを確認することです。
- go.sumファイルに保存されている別のハッシュ文字列とgo.modダウンロードファイルに基づいて、すべての文書が作成されますダウンロードしたパッケージを取りに行きます。
- パッケージをダウンロードしgo.sumの再計算値と比較して、キャッシュになり、コンパイルまたは手動で一貫性のないセキュリティエラーが報告されますモッズ検証行くたびに表示されます。
このメカニズムは、変更の開発ライフサイクル（依存ライブラリは、ほとんど更新されていないので、バージョン、重大なセキュリティ上の問題がない限り）を通じて、上記のメカニズムは、更新から他の人を避けるために、またはローカルに依存しませんローカルキャッシュに確立されています悪質な改ざんが、より多くのセキュリティ上の問題はこれで、リモート環境で発生するので、このメカニズムは大きなセキュリティ上のリスクがあります。
幸いなことに、彼は「sum.golang.org」にGOSUMDBがデフォルトに参加し、国のアクセスできない部分は、「sum.golang.google.cn」に変更することができます。次のように今働いメカニズムは次のとおりです。
- ファイルがgo.sum中にすでに存在しているかどうか、その後GOSUMDBチェックを行っていない場合は、最初にチェックを計算し、ダウンロードパッケージおよびチェックサム計算を取りに行く、チェックが書かれており、一貫性のあるgo.sumファイルされ、それ以外の場合はエラー
- 検証パケットとそれに対応するバージョンがgo.sumにすでに存在する場合、要求はGOSUMDB、残りの手順と同じくらい古いメカニズムではありません。
セキュリティが強化されました。
GOPRIVATE
最後に、それはあなたがそのようなパッケージを自動的に生成されたいくつかのRPCパッケージ、これらのプロキシのように、特定のまたはパッケージの特定のタイプがプロキシからダウンロードされていないを指定するには、Linuxのグロブワイルドカードの構文のようなものを使用することが可能なGOPRIVATE、デフォルトでは空であり、存在し、さらにアップアップロード意味がありませんので、あなたはGOPRIVATEでそれを記述する必要はありません。
そこGONOPROXYと呼ばれる環境変数それに類似したフォームの値が、基本的に同じ機能として、またあるが、それはGOPRIVATEをカバーします。例えば、すべてのパケットがプロキシから利用できるようになりますときnoneに設定されています。
これらの変化の観点から統一されたチームは、常に管理きめ細かい制御をパッケージ化できるソリューションを探している行き、NPMが、それはまだ成功への道上の固体ステップである、巨大なギャップがあるは、PyPI。
新機能標準ライブラリ
それぞれの新しいリリースでは、標準ライブラリに新しい機能をたくさんの新機能をもたらすでしょう、これは例外ではありません。
このセクションでは、新しい小型の機能だけでなく、重要な新しい変化をご紹介します。
変数が0の値であるかどうかを決定します
あなたは、変数の値を決定したい場合は、その後の拡張は複雑で面倒書くことは難しいだろう、特に自己定義型を0ゼロの値のいずれかのタイプが明確に定義されているgolangが、ゼロ値の不運に異なるさまざまな種類コード。
したがって、この機能では、新しいを反映して、操作を簡素化します：
package main
import (
"fmt"
"reflect"
)
func main() {
a := 0
b := 1
c := ""
d := "a"
fmt.Println(reflect.ValueOf(a).IsZero()) // true
fmt.Println(reflect.ValueOf(b).IsZero()) // false
fmt.Println(reflect.ValueOf(c).IsZero()) // true
fmt.Println(reflect.ValueOf(d).IsZero()) // false
}もちろん、高い消費を犠牲に反射性能なので、実際の環境を併せて参照して具体的な選択に一度。
イノベーションのエラー処理
実際には、ほとんどの革新的な、しかし、小修理の既存の練習。それはそれはまだそう全体的に、非常に奇妙な等しい値操作の癖を反映していなければならない値であるため、golangチームは、常にそのエラーを感じます。
のエラー（エラー・チェーン）のチェーンの概念を導入した最初の。
：1.13で、私たちのような、パッケージング誤差を達成するために、誤差のアンラップ方法を達成することができます
type PermError {
os.SyscallError
Pid uint
Uid uint
}
func (err *PermError) String() string {
return fmt.Sprintf("permission error:\npid:%v\nuid:\ninfo:%v", err.Pid, err.Uid, err.SyscallError)
}
func (err *PermError) Error() string {
return err.String()
}
// 重点在这里
func (err *PermError) Unwrap() error {
return err.SyscallError
}我々は、すべてのエラーが原因で、権限の問題のトリガーを含め、パーミッションベースのSyscallErrorエラーを詰めたとします。Stringそして、Error方法が間違った方法は、従来のカスタムに実装されている、我々は、フォーカスを見てUnwrap方法。
Unwrap文字通り、パッケージに、つまり、我々は再び分離し、返されたパッケージ間違ったの層の上に置きます。os.SyscallErrorあなたがのアンラップエラーまでということを理解していない最も原始への直接アクセスをドリルアップし続けることができるようにまた、アンラップを達成しました。私たちは、最上位のPermErrorというエラーに最初からエラー鎖であると述べました。
我々はアンラップ→指しているオブジェクトを返す場合は、次のような構造を形成します。
PermErrorという→os.SyscallError→エラー
：それはまた、より複雑な構造に存在してもよい
→ERR1 ___________
|
V
B ERR3→→→エラーERR2
あなただけのいくつかの追加情報が必要な、エラーの種類の単一の定義を所有していない場合、これは間違いなくあなたが頼ることができる、表情豊か間違っを高めないだろうfmt.Errorf。
newErr := fmt.Errorf("permission error:\npid:%v\nuid:\ninfo:%w", pid, uid, sysErr)
sysErr == newErr.(interface {Unwrap() error}).Unwrap()fmt.Errorf新しいプレースホルダは%w、彼が中にエラーメッセージを記入し、それがエラーを渡さ返しアンラップ新しいエラーの実現に戻ってくる、フォーマット文字列に一度だけ表示されます。インタフェースラッパーのもう一つの提案はまだ達成していないが、私は、標準ライブラリは上記のアプローチでラッパー関数を実装して使用してください。
エラー・チェーンがあるため、単純に誤差の値に基づいて、等号の決意を使用することはできないが、利点は、我々は今、エラーの種類に基づいて決定することができるということです。
エラーが彼の値のセマンティクスを表示できるようにするために継続するためには、エラーがバッグとそのアンラップと同様に補助機能です増加しました。
アンラップ
errors.Unwrapそのまま、アンラップ方法渡された引数を呼び出し、エラーのチェーン全体をトレースするためにそれを使用します。
このコードの前のセクションと同じように単純化することができます。
newErr := fmt.Errorf("permission error:\npid:%v\nuid:\ninfo:%w", pid, uid, sysErr)
sysErr == errors.Unwrap(newErr).Unwrap()あります
私たちは、別のエラーのため、時には唯一のパッケージで、このエラーは別が発生したときに生成され、そして我々は、エラー値を比較するだけです。この時間は、上にある、多くの場合、もはや開催されたのは比較的等しい数に言及しましたそれは、この時間は、あなたがする必要がありますすることができますerrors.Is役立ちます。
newErr := fmt.Errorf("permission error:\npid:%v\nuid:\ninfo:%w", pid, uid, sysErr)
errors.Is(newErr, sysErr)
errors.Is(newErr, os.ErrExists)そのため、常に==は間違いない代わりには使い、プログラムが延長されるか、私たちは未来が誤差との関係が変化しますかわからない知っていることはありません。
しかし、常に例外があること、例えば、io.EOFその意味が本当にプログラムエラーではありませんので、あなたは、比較することですを使用する必要はありません、と一般的に誰もそれをラップしないでしょう。
なので
伝統的な値に基づく判定に加えて、エラーの特定のタイプに共通の処理要件です。A、Bはエラーからのものである上記の例では、我々は、すべての誤差に基づいて、エラーが一般的なアプローチは、スイッチや能力多型塩基のクラスの比較に依拠することにあるハンドルと仮定する。
明白なアプローチは、重複したコードの多数につながる判断を切り替えることですが、難しい拡張し、唯一の組み合わせgolang年には継承されていないので、多型のみ、我々は唯一の間違ったチェーンを作るのを助けることができ、この時の機能をインタフェース実行時があるerrors.As助けるためには：
// 注意As的第二个参数只能是你需要判断的类型的指针，不可以直接传一个nil进去
var p1 *os.SyscallError
var p2 *os.PathError
errors.As(newErr, &p1)
errors.As(newErr, &p2)間違ったチェーンnewErr上型P1およびP2が配置されている場合は、trueを返す、非常に単純な多型効果を実装しています。いつものように置き換えるために使用されるif _, ok := err.(type); okようなコードを。
：もちろん、一方では上記の機能は、多くのコードを書くためにあなたが少なく作る、一方繰り返し、必要に応じて何回もさかのぼるので、2つのアドバイスがあり、特にエラーの長鎖で、反射に大きく依存しています
- 移行パッケージを行い、何も間接の層が解決することはできません追加することではありませんが、あまりにも多くの中間層だけではなく、パフォーマンスが継続的なメンテナンスを妨害する影響します。
- あなたが本当にパフォーマンスを気にするだけでなく、既存のエラーの拡大を確実にするためにした場合（例えば、io.EOFのために）存在していない、そして伝統的なプログラムは損はない使用しています。
個人的に私は新しいエラーハンドリング方法はどのような自然の問題を解決しないと思いますが、最初のステップは、試してみて、あるいは認識の価値があります。