Saya setuju ini adalah cara terbaik ke depan: memperbaiki masalah paling umum dengan desain sederhana.

Saya tidak ingin bersepeda (jangan ragu untuk menunda percakapan ini), tetapi Rust pergi ke sana dan akhirnya menyelesaikan dengan ? operator postfix daripada fungsi bawaan, untuk meningkatkan keterbacaan.

Proposal gophercon mengutip ? dalam gagasan yang dipertimbangkan dan memberikan tiga alasan mengapa itu dibuang: yang pertama ("transfer aliran kontrol sebagai aturan umum disertai dengan kata kunci") dan yang ketiga ("penangan lebih didefinisikan secara alami dengan kata kunci, jadi cek juga harus") tidak berlaku lagi. Yang kedua adalah gaya: ia mengatakan bahwa, bahkan jika operator postfix bekerja lebih baik untuk rantai, masih dapat membaca lebih buruk dalam beberapa kasus seperti:

check io.Copy(w, check newReader(foo))

daripada:

io.Copy(w, newReader(foo)?)?

tapi sekarang kita akan memiliki:

try(io.Copy(w, try(newReader(foo))))

yang menurut saya jelas lebih buruk dari ketiganya, karena bahkan tidak jelas lagi yang merupakan fungsi utama yang dipanggil.

Jadi inti dari komentar saya adalah bahwa ketiga alasan yang disebutkan dalam proposal gophercon untuk tidak menggunakan ? tidak berlaku untuk proposal try ini; ? ringkas, sangat mudah dibaca, tidak mengaburkan struktur pernyataan (dengan hierarki panggilan fungsi internal), dan dapat dirantai. Ini menghilangkan lebih banyak kekacauan dari tampilan, sementara tidak mengaburkan aliran kontrol lebih dari yang sudah diusulkan try() .

Untuk memperjelas:

Melakukan

func f() (n int, err error) {
  n = 7
  try(errors.New("x"))
  // ...
}

kembali (0, "x") atau (7, "x")? Saya akan berasumsi yang terakhir.

Apakah pengembalian kesalahan harus diberi nama jika tidak ada dekorasi atau penanganan (seperti dalam fungsi pembantu internal)? Saya akan berasumsi tidak.

Contoh Anda mengembalikan 7, errors.New("x") . Ini harus jelas dalam dokumen lengkap yang akan segera dikirimkan (https://golang.org/cl/180557).

Parameter hasil kesalahan tidak perlu diberi nama untuk menggunakan try . Itu hanya perlu diberi nama jika fungsi perlu merujuknya ke fungsi yang ditangguhkan atau di tempat lain.

Saya benar-benar tidak senang dengan _function_ bawaan yang memengaruhi aliran kontrol pemanggil. Saya menghargai ketidakmungkinan menambahkan kata kunci baru di Go 1, tetapi mengatasi masalah itu dengan fungsi bawaan ajaib sepertinya salah bagi saya. Membayangi built-in lainnya tidak memiliki hasil yang tidak terduga seperti perubahan aliran kontrol.

Saya tidak suka tampilan postfix ? , tapi saya pikir itu masih bagus try() .

Sunting: Yah, saya benar-benar lupa bahwa kepanikan itu ada dan bukan kata kunci.

Proposal terperinci sekarang ada di sini (peningkatan pemformatan yang tertunda, akan segera hadir) dan mudah-mudahan akan menjawab banyak pertanyaan.

@dominikh Proposal terperinci membahas ini secara panjang lebar, tetapi harap dicatat bahwa panic dan recover adalah dua bawaan yang juga memengaruhi aliran kontrol.

Satu klarifikasi / saran untuk perbaikan:

if the last argument supplied to try, of type error, is not nil, the enclosing function’s error result variable (...) is set to that non-nil error value before the enclosing function returns

Bisakah ini mengatakan is set to that non-nil error value and the enclosing function returns ? (s/sebelum/dan)

Pada pembacaan pertama, before the enclosing function returns sepertinya akan _akhirnya_ menetapkan nilai kesalahan di beberapa titik di masa depan tepat sebelum fungsi dikembalikan - mungkin di baris selanjutnya. Interpretasi yang benar adalah bahwa try dapat menyebabkan fungsi saat ini kembali. Itu perilaku yang mengejutkan untuk bahasa saat ini, jadi teks yang lebih jelas akan disambut.

Saya pikir ini hanya gula, dan sejumlah kecil lawan vokal menggoda golang tentang penggunaan berulang mengetik if err != nil ... dan seseorang menganggapnya serius. Saya tidak berpikir itu masalah. Satu-satunya hal yang hilang adalah dua bawaan ini:

https://github.com/purpleidea/mgmt/blob/a235b760dc3047a0d66bb0b9d63c25bc746ed274/util/errwrap/errwrap.go#L26

Tidak yakin mengapa ada orang yang menulis fungsi seperti ini, tetapi untuk apa output yang diharapkan

try(foobar())

Jika foobar mengembalikan (error, error)

Saya menarik kembali kekhawatiran saya sebelumnya tentang aliran kontrol dan saya tidak lagi menyarankan menggunakan ? . Saya minta maaf atas tanggapan spontan (meskipun saya ingin menunjukkan ini tidak akan terjadi seandainya masalah diajukan _setelah_ proposal lengkap tersedia).

Saya tidak setuju dengan perlunya penanganan kesalahan yang disederhanakan, tetapi saya yakin itu adalah pertempuran yang kalah. try seperti yang tercantum dalam proposal tampaknya merupakan cara yang paling tidak buruk untuk melakukannya.

@webermaster Hanya hasil error terakhir yang khusus untuk ekspresi yang diteruskan ke try , seperti yang dijelaskan dalam dokumen proposal.

Seperti @dominikh , saya juga tidak setuju dengan perlunya penanganan kesalahan yang disederhanakan.

Ini memindahkan kompleksitas vertikal ke kompleksitas horizontal yang jarang merupakan ide bagus.

Jika saya benar-benar harus memilih antara menyederhanakan proposal penanganan kesalahan, ini akan menjadi proposal pilihan saya.

Akan sangat membantu jika ini dapat disertai (pada beberapa tahap penerimaan) dengan alat untuk mengubah kode Go untuk menggunakan try di beberapa subset fungsi pengembalian kesalahan di mana transformasi seperti itu dapat dengan mudah dilakukan tanpa mengubah semantik. Tiga manfaat terjadi pada saya:

• Saat mengevaluasi proposal ini, ini akan memungkinkan orang dengan cepat memahami bagaimana try dapat digunakan dalam basis kode mereka.
• Jika try masuk ke versi Go yang akan datang, orang mungkin ingin mengubah kode mereka untuk menggunakannya. Memiliki alat untuk mengotomatiskan kasus mudah akan banyak membantu.
• Memiliki cara untuk mengubah basis kode besar dengan cepat untuk menggunakan try akan memudahkan untuk memeriksa efek implementasi dalam skala besar. (Kebenaran, kinerja, dan ukuran kode, katakanlah.) Implementasinya mungkin cukup sederhana untuk membuat pertimbangan ini diabaikan.

Saya hanya ingin mengungkapkan bahwa menurut saya try(foo()) yang sebenarnya keluar dari fungsi panggilan menghilangkan dari kita isyarat visual bahwa aliran fungsi dapat berubah tergantung pada hasilnya.

Saya merasa saya dapat bekerja dengan try jika sudah cukup terbiasa, tetapi saya juga merasa kita akan membutuhkan dukungan IDE tambahan (atau semacamnya) untuk menyorot try untuk mengenali aliran implisit dalam tinjauan kode secara efisien /sesi debug

Hal yang paling saya khawatirkan adalah kebutuhan untuk menamai nilai pengembalian hanya agar pernyataan penangguhan senang.

Saya pikir masalah penanganan kesalahan keseluruhan yang dikeluhkan komunitas adalah kombinasi dari boilerplate if err != nil DAN menambahkan konteks ke kesalahan. FAQ dengan jelas menyatakan bahwa yang terakhir sengaja ditinggalkan sebagai masalah terpisah, tetapi saya merasa ini menjadi solusi yang tidak lengkap, tetapi saya akan bersedia memberikannya kesempatan setelah memikirkan 2 hal ini:

1. Deklarasikan err di awal fungsi.
   Apakah ini bekerja? Saya ingat masalah dengan penundaan & hasil yang tidak disebutkan namanya. Jika tidak proposal perlu mempertimbangkan ini.

func sample() (string, error) {
  var err error
  defer fmt.HandleErrorf(&err, "whatever")
  s := try(f())
  return s, nil
}

1. Tetapkan nilai seperti yang kita lakukan sebelumnya, tetapi gunakan fungsi helper wrapf yang memiliki if err != nil boilerplate.

func sample() (string, error) {
  s, err := f()
  try(wrapf(err, "whatever"))
  return s, nil
}
func wrapf(err error, format string, ...v interface{}) error {
  if err != nil {
    // err = wrapped error
  }
  return err
}

Jika salah satu bekerja, saya bisa menghadapinya.

func sample() (string, error) {
  var err error
  defer fmt.HandleErrorf(&err, "whatever")
  s := try(f())
  return s, nil
}

Ini tidak akan berhasil. Penangguhan akan memperbarui variabel err lokal, yang tidak terkait dengan nilai kembalian.

func sample() (string, error) {
  s, err := f()
  try(wrapf(err, "whatever"))
  return s, nil
}
func wrapf(err error, format string, ...v interface{}) error {
  if err != nil {
    // err = wrapped error
  }
  return err
}

Itu harus bekerja. Itu akan memanggil wrapf bahkan pada kesalahan nihil.
Ini juga akan (terus) berfungsi, dan IMO jauh lebih jelas:

func sample() (string, error) {
  s, err := f()
  if err != nil {
      return "", wrap(err)
  }
  return s, nil
}

Tidak ada yang akan membuat Anda menggunakan try .

Tidak yakin mengapa ada orang yang menulis fungsi seperti ini, tetapi untuk apa output yang diharapkan

try(foobar())

Jika foobar mengembalikan (error, error)

Mengapa Anda mengembalikan lebih dari satu kesalahan dari suatu fungsi? Jika Anda mengembalikan lebih dari satu kesalahan dari fungsi, mungkin fungsi harus dipecah menjadi dua yang terpisah sejak awal, masing-masing hanya mengembalikan satu kesalahan.

Bisakah Anda menguraikan dengan sebuah contoh?

@cespare : Seharusnya seseorang dapat menulis go fix yang menulis ulang kode yang ada cocok untuk try sehingga menggunakan try . Mungkin berguna untuk merasakan bagaimana kode yang ada dapat disederhanakan. Kami tidak mengharapkan perubahan signifikan dalam ukuran atau kinerja kode, karena try hanyalah gula sintaksis, menggantikan pola umum dengan bagian kode sumber yang lebih pendek yang pada dasarnya menghasilkan kode keluaran yang sama. Perhatikan juga bahwa kode yang menggunakan try akan terikat untuk menggunakan versi Go yang setidaknya merupakan versi di mana try diperkenalkan.

@lestrrat : Setuju bahwa seseorang harus belajar bahwa try dapat mengubah aliran kontrol. Kami menduga bahwa IDE dapat menyorotinya dengan cukup mudah.

@Goodwine : Seperti yang sudah ditunjukkan oleh @randall77 , saran pertama Anda tidak akan berhasil. Salah satu opsi yang telah kami pikirkan (tetapi tidak dibahas dalam dokumen) adalah kemungkinan memiliki beberapa variabel yang dideklarasikan sebelumnya yang menunjukkan hasil error (jika ada di tempat pertama). Itu akan menghilangkan kebutuhan untuk menamai hasil itu agar dapat digunakan dalam defer . Tapi itu akan lebih ajaib; tampaknya tidak dibenarkan. Masalah dengan penamaan hasil pengembalian pada dasarnya kosmetik, dan yang paling penting adalah dalam API yang dibuat secara otomatis yang dilayani oleh go doc dan teman-teman. Akan mudah untuk mengatasi ini di alat-alat itu (lihat juga FAQ dokumen desain terperinci tentang hal ini).

@nictuku : Mengenai saran Anda untuk klarifikasi (s/before/and/): Saya pikir kode tepat sebelum paragraf yang Anda maksud menjelaskan apa yang sebenarnya terjadi, tapi saya mengerti maksud Anda, s/before/and/ may membuat prosa lebih jelas. Aku akan membuat perubahan.

Lihat CL 180637 .

Saya sebenarnya sangat menyukai proposal ini. Namun, saya punya satu kritik. Titik keluar dari fungsi di Go selalu ditandai dengan return . Kepanikan juga merupakan titik keluar, namun itu adalah kesalahan besar yang biasanya tidak dimaksudkan untuk ditemui.

Membuat titik keluar dari fungsi yang bukan return , dan dimaksudkan untuk menjadi biasa, dapat menyebabkan kode yang jauh lebih mudah dibaca. Saya telah mendengar tentang ini dalam sebuah ceramah dan sulit untuk melupakan keindahan bagaimana kode ini disusun:

func CopyFile(src, dst string) error {
    r, err := os.Open(src)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    defer r.Close()

    w, err := os.Create(dst)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if _, err := io.Copy(w, r); err != nil {
        w.Close()
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if err := w.Close(); err != nil {
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
}

Kode ini mungkin terlihat seperti kekacauan besar, dan _dimaksudkan_ oleh draft penanganan kesalahan, tetapi mari kita bandingkan dengan hal yang sama dengan try .

func CopyFile(src, dst string) error {
    defer func() {
        err = fmt.Errorf("copy %s %s: %v", src, dst, err)
    }()
    r, err := try(os.Open(src))
    defer r.Close()

    w, err := try(os.Create(dst))

    defer w.Close()
    defer os.Remove(dst)
    try(io.Copy(w, r))
    try(w.Close())

    return nil
}

Anda mungkin melihat ini pada pandangan pertama dan berpikir itu terlihat lebih baik, karena ada lebih sedikit kode yang diulang. Namun, sangat mudah untuk menemukan semua titik yang dikembalikan oleh fungsi pada contoh pertama. Mereka semua menjorok dan dimulai dengan return , diikuti dengan spasi. Ini karena fakta bahwa semua pengembalian bersyarat _harus_ berada di dalam blok bersyarat, sehingga diindentasi oleh standar gofmt . return juga, seperti yang dinyatakan sebelumnya, satu-satunya cara untuk meninggalkan fungsi tanpa mengatakan bahwa kesalahan besar telah terjadi. Pada contoh kedua, hanya ada satu return , jadi sepertinya satu-satunya hal yang harus dikembalikan oleh fungsi _ever_ adalah nil . Dua panggilan try terakhir mudah dilihat, tetapi dua panggilan pertama sedikit lebih sulit, dan akan lebih sulit lagi jika panggilan tersebut bersarang di suatu tempat, misalnya proc := try(os.FindProcess(try(strconv.Atoi(os.Args[1])))) .

Kembali dari suatu fungsi tampaknya merupakan hal yang "suci" untuk dilakukan, itulah sebabnya saya pribadi berpikir bahwa semua titik keluar dari suatu fungsi harus ditandai dengan return .

Seseorang telah menerapkan ini 5 tahun yang lalu. Jika Anda tertarik, Anda bisa
coba fitur ini

https://news.ycombinator.com/item?id=20101417

Saya menerapkan try() di Go lima tahun lalu dengan preprosesor AST dan menggunakannya dalam proyek nyata, itu cukup bagus: https://github.com/lunixbochs/og

Berikut adalah beberapa contoh saya menggunakannya dalam fungsi error-check-heavy: https://github.com/lunixbochs/poxd/blob/master/tls.go#L13

Saya menghargai upaya yang dilakukan untuk ini. Saya pikir ini adalah solusi paling menarik yang pernah saya lihat sejauh ini. Tapi saya pikir itu memperkenalkan banyak pekerjaan saat debugging. Membuka bungkus mencoba dan menambahkan blok if setiap kali saya men-debug dan membungkusnya kembali ketika saya selesai itu membosankan. Dan saya juga merasa ngeri tentang variabel err ajaib yang perlu saya pertimbangkan. Saya tidak pernah terganggu oleh pemeriksaan kesalahan eksplisit jadi mungkin saya orang yang salah untuk bertanya. Itu selalu menurut saya "siap untuk debug".

@griesemer
Masalah saya dengan penggunaan penangguhan yang Anda usulkan sebagai cara untuk menangani pembungkusan kesalahan adalah bahwa perilaku dari cuplikan yang saya tunjukkan (diulangi di bawah) tidak terlalu umum AFAICT, dan karena sangat jarang maka saya dapat membayangkan orang menulis ini berpikir itu berhasil ketika tidak.

Seperti .. seorang pemula tidak akan tahu ini, jika mereka memiliki bug karena ini mereka tidak akan pergi "tentu saja, saya perlu pengembalian bernama", mereka akan stres karena seharusnya berhasil dan tidak.

var err error
defer fmt.HandleErrorf(err);

try sudah terlalu ajaib sehingga Anda sebaiknya melanjutkan dan menambahkan nilai kesalahan implisit itu. Pikirkan pemula, bukan pada mereka yang tahu semua nuansa Go. Jika tidak cukup jelas, saya pikir itu bukan solusi yang tepat.

Atau... Tidak menyarankan menggunakan penangguhan seperti ini, coba cara lain yang lebih aman tetapi tetap dapat dibaca.

@deanveloper Memang benar bahwa proposal ini (dan dalam hal ini, proposal apa pun yang mencoba mencoba hal yang sama) akan menghapus pernyataan return yang terlihat secara eksplisit dari kode sumber - itulah inti dari proposal, bukan? Untuk menghapus boilerplate dari pernyataan if dan returns yang semuanya sama. Jika Anda ingin menyimpan return , jangan gunakan try .

Kami terbiasa segera mengenali pernyataan return (dan panic ) karena begitulah cara aliran kontrol ini diekspresikan dalam Go (dan banyak bahasa lainnya). Tampaknya tidak berlebihan bahwa kita juga akan mengenali try sebagai aliran kontrol yang berubah setelah beberapa orang terbiasa, seperti yang kita lakukan untuk return . Saya tidak ragu bahwa dukungan IDE yang baik akan membantu dalam hal ini juga.

Saya memiliki dua kekhawatiran:

• pengembalian bernama sangat membingungkan, dan ini mendorong mereka dengan kasus penggunaan baru dan penting
• ini akan mencegah menambahkan konteks ke kesalahan

Dalam pengalaman saya, menambahkan konteks ke kesalahan segera setelah setiap situs panggilan sangat penting untuk memiliki kode yang dapat dengan mudah di-debug. Dan pengembalian bernama telah menyebabkan kebingungan bagi hampir setiap pengembang Go yang saya kenal di beberapa titik.

Masalah gaya yang lebih kecil adalah sangat disayangkan berapa banyak baris kode yang sekarang akan dibungkus try(actualThing()) . Saya dapat membayangkan melihat sebagian besar baris dalam basis kode yang dibungkus try() . Itu terasa disayangkan.

Saya pikir masalah ini akan diatasi dengan tweak:

a, b, err := myFunc()
check(err, "calling myFunc on %v and %v", a, b)

check() akan berperilaku seperti try() , tetapi akan menghilangkan perilaku melewati nilai pengembalian fungsi secara umum, dan sebagai gantinya akan memberikan kemampuan untuk menambahkan konteks. Itu masih akan memicu pengembalian.

Ini akan mempertahankan banyak keuntungan dari try() :

• itu adalah bawaan
• itu mengikuti aliran kontrol yang ada WRT untuk menunda
• itu selaras dengan praktik yang ada untuk menambahkan konteks ke kesalahan dengan baik
• itu sejajar dengan proposal dan pustaka saat ini untuk pembungkusan kesalahan, seperti errors.Wrap(err, "context message")
• itu menghasilkan situs panggilan yang bersih: tidak ada boilerplate di baris a, b, err := myFunc()
• menjelaskan kesalahan dengan defer fmt.HandleError(&err, "msg") masih dimungkinkan, tetapi tidak perlu didorong.
• tanda tangan check sedikit lebih sederhana, karena tidak perlu mengembalikan sejumlah argumen dari fungsi yang dibungkusnya.

@s4n-gt Terima kasih untuk tautan ini. Saya tidak menyadarinya.

@Goodwine Poin diambil. Alasan untuk tidak memberikan lebih banyak dukungan penanganan kesalahan langsung dibahas dalam dokumen desain secara rinci. Ini juga merupakan fakta bahwa selama satu tahun atau lebih (sejak rancangan desain diterbitkan di Gophercon tahun lalu) tidak ada solusi yang memuaskan untuk penanganan kesalahan eksplisit yang muncul. Itulah sebabnya proposal ini sengaja mengabaikannya (dan sebaliknya menyarankan untuk menggunakan defer ). Proposal ini masih membuka pintu untuk perbaikan di masa depan dalam hal itu.

Proposal menyebutkan mengubah pengujian paket untuk memungkinkan pengujian dan tolok ukur mengembalikan kesalahan. Meskipun tidak akan menjadi "perubahan perpustakaan sederhana", kami dapat mempertimbangkan untuk menerima func main() error juga. Itu akan membuat menulis skrip kecil jauh lebih bagus. Semantik akan setara dengan:

func main() {
  if err := newmain(); err != nil {
    println(err.Error())
    os.Exit(1)
  }
}

Satu kritik terakhir. Sebenarnya bukan kritik terhadap proposal itu sendiri, melainkan kritik terhadap tanggapan bersama terhadap argumen tandingan "fungsi pengontrol aliran".

Tanggapan untuk "Saya tidak suka bahwa suatu fungsi mengendalikan aliran" adalah bahwa " panic juga mengontrol aliran program!". Namun, ada beberapa alasan mengapa panic lebih baik melakukan ini yang tidak berlaku untuk try .

1. panic ramah untuk pemrogram pemula karena apa yang dilakukannya intuitif, terus membuka bungkus tumpukan. Seseorang bahkan tidak perlu mencari cara kerja panic untuk memahami apa yang dilakukannya. Pemrogram pemula bahkan tidak perlu khawatir tentang recover , karena pemula biasanya tidak membangun mekanisme pemulihan panik, terutama karena mereka hampir selalu kurang menguntungkan daripada sekadar menghindari kepanikan sejak awal.

2. panic adalah nama yang mudah dilihat. Ini membawa kekhawatiran, dan itu perlu. Jika seseorang melihat panic dalam basis kode, mereka harus segera memikirkan cara _menghindari_ kepanikan, meskipun itu sepele.

3. Membonceng dari poin terakhir, panic tidak dapat disarangkan dalam panggilan, membuatnya lebih mudah untuk dilihat.

Tidak apa-apa panik untuk mengontrol aliran program karena sangat mudah dikenali, dan intuitif untuk apa yang dilakukannya.

Fungsi try tidak memenuhi salah satu dari poin ini.

1. Seseorang tidak dapat menebak apa yang dilakukan try tanpa melihat dokumentasinya. Banyak bahasa menggunakan kata kunci dengan cara yang berbeda, sehingga sulit untuk memahami apa artinya di Go.

2. try tidak menarik perhatian saya, terutama jika itu adalah sebuah fungsi. _Terutama_ ketika penyorotan sintaks akan menyorotnya sebagai suatu fungsi. _TERUTAMA_ setelah berkembang dalam bahasa seperti Java, di mana try dipandang sebagai boilerplate yang tidak perlu (karena pengecualian yang diperiksa).

3. try dapat digunakan dalam argumen untuk panggilan fungsi, seperti contoh saya di komentar saya sebelumnya proc := try(os.FindProcess(try(strconv.Atoi(os.Args[1])))) . Ini membuatnya semakin sulit dikenali.

Mata saya mengabaikan fungsi try , bahkan ketika saya secara khusus mencarinya. Mata saya akan melihatnya, tetapi langsung beralih ke panggilan os.FindProcess atau strconv.Atoi . try adalah pengembalian bersyarat. Aliran kontrol DAN pengembalian keduanya ditahan di atas tumpuan di Go. Semua aliran kontrol dalam suatu fungsi diindentasi, dan semua pengembalian dimulai dengan return . Menggabungkan kedua konsep ini bersama-sama menjadi panggilan fungsi yang mudah terlewatkan terasa agak aneh.

Komentar ini dan komentar terakhir saya adalah satu-satunya kritik nyata saya terhadap ide tersebut. Saya pikir saya mungkin tidak menyukai proposal ini, tetapi saya masih berpikir bahwa ini adalah kemenangan keseluruhan untuk Go. Solusi ini masih terasa lebih mirip Go daripada solusi lainnya. Jika ini ditambahkan saya akan senang, namun saya pikir itu masih bisa ditingkatkan, saya tidak yakin bagaimana caranya.

@buchanae menarik. Namun, seperti yang tertulis, ini memindahkan pemformatan gaya fmt dari sebuah paket ke dalam bahasa itu sendiri, yang membuka sekaleng worm.

Namun, seperti yang tertulis, ini memindahkan pemformatan gaya fmt dari sebuah paket ke dalam bahasa itu sendiri, yang membuka sekaleng worm.

Poin bagus. Contoh yang lebih sederhana:

a, b, err := myFunc()
check(err, "calling myFunc")

@buchanae Kami telah mempertimbangkan untuk membuat penanganan kesalahan eksplisit lebih terhubung langsung dengan try - silakan lihat dokumen desain terperinci, khususnya bagian tentang iterasi Desain. Saran spesifik Anda tentang check hanya akan memungkinkan untuk menambah kesalahan melalui sesuatu seperti fmt.Errorf seperti API (sebagai bagian dari check ), jika saya mengerti dengan benar. Secara umum, orang mungkin ingin melakukan segala macam hal dengan kesalahan, tidak hanya membuat yang baru yang merujuk ke yang asli melalui string kesalahannya.

Sekali lagi, proposal ini tidak berusaha untuk menyelesaikan semua situasi penanganan kesalahan. Saya menduga dalam banyak kasus try masuk akal untuk kode yang sekarang terlihat seperti ini:

a, b, c, ... err := try(someFunctionCall())
if err != nil {
   return ..., err
}

Ada banyak sekali kode yang terlihat seperti ini. Dan tidak setiap bagian dari kode yang terlihat seperti ini membutuhkan lebih banyak penanganan kesalahan. Dan di mana defer tidak benar, seseorang masih dapat menggunakan pernyataan if .

Saya tidak mengikuti baris ini:

defer fmt.HandleErrorf(&err, “foobar”)

Ini menjatuhkan kesalahan masuk di lantai, yang tidak biasa. Apakah itu dimaksudkan untuk digunakan sesuatu yang lebih seperti ini?

defer fmt.HandleErrorf(&err, “foobar: %v”, err)

Duplikasi err agak gagap-y. Ini tidak benar-benar langsung sesuai dengan proposal, hanya komentar sampingan tentang doc.

Saya berbagi dua masalah yang diangkat oleh @buchanae , re: bernama pengembalian dan kesalahan kontekstual.

Saya menemukan pengembalian bernama agak merepotkan seperti itu; Saya pikir mereka hanya benar-benar bermanfaat sebagai dokumentasi. Bersandar pada mereka lebih berat adalah kekhawatiran. Maaf untuk menjadi sangat kabur, meskipun. Saya akan lebih memikirkan hal ini dan memberikan beberapa pemikiran yang lebih konkret.

Saya pikir ada kekhawatiran nyata bahwa orang akan berusaha keras untuk menyusun kode mereka sehingga try dapat digunakan, dan oleh karena itu menghindari menambahkan konteks ke kesalahan. Ini adalah waktu yang sangat aneh untuk memperkenalkan ini, mengingat kami baru saja menyediakan cara yang lebih baik untuk menambahkan konteks ke kesalahan melalui fitur pembungkusan kesalahan resmi.

Saya benar-benar berpikir bahwa try seperti yang diusulkan membuat beberapa kode secara signifikan lebih baik. Inilah fungsi yang saya pilih kurang lebih secara acak dari basis kode proyek saya saat ini, dengan beberapa nama diubah. Saya sangat terkesan dengan cara kerja try saat menetapkan bidang struct. (Itu dengan asumsi pembacaan proposal saya benar, dan ini berhasil?)

Kode yang ada:

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        err := dbfile.RunMigrations(db, dbMigrations)
        if err != nil {
                return nil, err
        }
        t := &Thing{
                thingy: thingy,
        }
        t.scanner, err = newScanner(thingy, db, client)
        if err != nil {
                return nil, err
        }
        t.initOtherThing()
        return t, nil
}

Dengan try :

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        try(dbfile.RunMigrations(db, dbMigrations))
        t := &Thing{
                thingy:  thingy,
                scanner: try(newScanner(thingy, db, client)),
        }
        t.initOtherThing()
        return t, nil
}

Tidak ada kehilangan keterbacaan, kecuali mungkin bahwa newScanner mungkin gagal. Tapi kemudian di dunia dengan try programmer Go akan lebih sensitif terhadap kehadirannya.

@josharian Mengenai main mengembalikan error : Bagi saya tampaknya hanya fungsi pembantu kecil Anda yang diperlukan untuk mendapatkan efek yang sama. Saya tidak yakin mengubah tanda tangan main dibenarkan.

Mengenai contoh "foobar": Itu hanya contoh yang buruk. Saya mungkin harus mengubahnya. Terima kasih telah mengangkatnya.

defer fmt.HandleErrorf(&err, “foobar: %v”, err)

Sebenarnya itu tidak benar, karena err akan dievaluasi terlalu dini. Ada beberapa cara untuk mengatasi ini, tetapi tidak ada yang sebersih HandleErrorf asli (saya pikir cacat). Saya pikir akan lebih baik untuk memiliki satu atau dua contoh fungsi pembantu yang lebih realistis.

EDIT: bug evaluasi awal ini ada dalam contoh
menjelang akhir doc:

defer fmt.HandleErrorf(&err, "copy %s %s: %v", src, dst, err)

@adg Ya, try dapat digunakan seperti yang Anda gunakan dalam contoh Anda. Saya membiarkan komentar Anda kembali: pengembalian bernama berdiri apa adanya.

orang mungkin ingin melakukan segala macam hal dengan kesalahan, tidak hanya membuat yang baru yang merujuk ke yang asli melalui string kesalahannya.

try tidak mencoba menangani semua jenis kesalahan yang ingin dilakukan orang, hanya kesalahan yang dapat kami temukan cara praktis untuk membuatnya lebih sederhana. Saya percaya contoh check saya berjalan di jalur yang sama.

Dalam pengalaman saya, bentuk paling umum dari kode penanganan kesalahan adalah kode yang pada dasarnya menambahkan jejak tumpukan, terkadang dengan konteks tambahan. Saya telah menemukan bahwa jejak tumpukan sangat penting untuk debugging, di mana saya mengikuti pesan kesalahan melalui kode.

Tapi, mungkin proposal lain akan menambahkan jejak tumpukan ke semua kesalahan? Aku kehilangan jejak.

Dalam contoh yang diberikan @adg , ada dua potensi kegagalan tetapi tidak ada konteks. Jika newScanner dan RunMigrations sendiri tidak memberikan pesan yang memberi petunjuk Anda ke mana yang salah, maka Anda dibiarkan menebak-nebak.

Dalam contoh yang diberikan @adg , ada dua potensi kegagalan tetapi tidak ada konteks. Jika newScanner dan RunMigrations sendiri tidak memberikan pesan yang memberi tahu Anda mana yang salah, maka Anda tidak perlu menebak-nebak.

Itu benar, dan itulah pilihan desain yang kami buat di bagian kode khusus ini. Kami melakukan banyak kesalahan bungkus di bagian lain dari kode.

Saya berbagi keprihatinan sebagai @deanveloper dan yang lainnya bahwa itu mungkin membuat debugging lebih sulit. Memang benar bahwa kita dapat memilih untuk tidak menggunakannya, tetapi gaya dependensi pihak ketiga tidak berada di bawah kendali kita.
Jika if err := ... { return err } yang kurang berulang adalah poin utama, saya ingin tahu apakah "pengembalian bersyarat" sudah cukup, seperti yang diusulkan https://github.com/golang/go/issues/27794 .

        return nil, err if f, err := os.Open(...)
        return nil, err if _, err := os.Write(...)

Saya pikir ? akan lebih cocok daripada try , dan selalu harus mengejar defer untuk kesalahan juga akan rumit.

Ini juga menutup gerbang untuk memiliki pengecualian menggunakan try/catch selamanya.

Ini juga menutup gerbang untuk memiliki pengecualian menggunakan try/catch selamanya.

Saya _lebih_ dari baik-baik saja dengan ini.

Saya setuju dengan beberapa masalah yang diangkat di atas mengenai menambahkan konteks ke kesalahan. Saya perlahan mencoba untuk beralih dari hanya mengembalikan kesalahan menjadi selalu menghiasinya dengan konteks dan kemudian mengembalikannya. Dengan proposal ini, saya harus sepenuhnya mengubah fungsi saya untuk menggunakan params pengembalian bernama (yang saya rasa aneh karena saya jarang menggunakan pengembalian telanjang).

Seperti yang dikatakan @griesemer :

Sekali lagi, proposal ini tidak berusaha untuk menyelesaikan semua situasi penanganan kesalahan. Saya menduga dalam banyak kasus coba masuk akal untuk kode yang sekarang pada dasarnya terlihat seperti ini:
a, b, c, ... err := coba(someFunctionCall())
jika salah != nihil {
kembali..., err
}
Ada banyak sekali kode yang terlihat seperti ini. Dan tidak setiap bagian dari kode yang terlihat seperti ini membutuhkan lebih banyak penanganan kesalahan. Dan di mana penangguhan tidak benar, seseorang masih dapat menggunakan pernyataan if.

Ya, tetapi seharusnya tidak baik, kode idiomatik selalu membungkus/menghias kesalahannya? Saya percaya itu sebabnya kami memperkenalkan mekanisme penanganan kesalahan yang disempurnakan untuk menambahkan kesalahan konteks/bungkus di stdlib. Seperti yang saya lihat, proposal ini sepertinya hanya mempertimbangkan kasus penggunaan paling dasar.

Selain itu, proposal ini hanya membahas kasus membungkus/mendekorasi beberapa kemungkinan situs pengembalian kesalahan di _satu tempat_, menggunakan parameter bernama dengan panggilan penangguhan.

Tetapi itu tidak melakukan apa pun untuk kasus ketika seseorang perlu menambahkan konteks yang berbeda ke kesalahan yang berbeda dalam satu fungsi. Misalnya, sangat penting untuk mendekorasi kesalahan DB untuk mendapatkan informasi lebih lanjut tentang dari mana asalnya (dengan asumsi tidak ada jejak tumpukan)

Ini adalah contoh kode nyata yang saya miliki -

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    if err != nil {
        return err
    }
    var res int64
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    if err != nil {
        tx.Rollback()
        return fmt.Errorf("insert table: %w", err)
    }

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    if err != nil {
        tx.Rollback()
        return fmt.Errorf("insert table2: %w", err)
    }
    return tx.Commit()
}

Menurut usulan:

Jika augmentasi atau pembungkusan kesalahan diinginkan, ada dua pendekatan: Tetap dengan pernyataan if yang dicoba-dan-benar, atau, sebagai alternatif, "deklarasikan" penangan kesalahan dengan pernyataan penangguhan:

Saya pikir ini akan termasuk dalam kategori "tetap dengan pernyataan if yang sudah dicoba dan benar". Saya berharap proposal dapat ditingkatkan untuk mengatasi hal ini juga.

Saya sangat menyarankan tim Go memprioritaskan obat generik , karena di situlah Go paling banyak mendengar kritik, dan menunggu penanganan kesalahan. Teknik hari ini tidak terlalu menyakitkan (tapi go fmt harus membiarkannya duduk di satu baris).

Konsep try() memiliki semua masalah check dari check/handle:

1. Itu tidak membaca seperti Go. Orang menginginkan sintaks penugasan, tanpa tes nil berikutnya, seperti yang terlihat seperti Go. Tiga belas tanggapan terpisah untuk diperiksa/ditangani menyarankan hal ini; lihat _Tema Berulang_ di sini:
   https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

   f, #      := os.Open(...) // return on error
   f, #panic := os.Open(...) // panic on error
   f, #hname := os.Open(...) // invoke named handler on error
   // # is any available symbol or unambiguous pair
   

2. Penyatuan panggilan fungsi yang mengembalikan kesalahan mengaburkan urutan operasi, dan menghalangi debugging. Keadaan saat kesalahan terjadi, dan oleh karena itu urutan panggilan, harus jelas, tetapi ini bukan:
   try(step4(try(step1()), try(step3(try(step2())))))
   Sekarang ingat bahwa bahasa melarang:
   f(t ? a : b) dan f(a++)

3. Akan sepele untuk mengembalikan kesalahan tanpa konteks. Alasan utama pemeriksaan/pegangan adalah untuk mendorong kontekstualisasi.

4. Itu terkait dengan mengetik error dan nilai pengembalian terakhir. Jika kami perlu memeriksa nilai/tipe pengembalian lain untuk status luar biasa, kami kembali ke: if errno := f(); errno != 0 { ... }

5. Itu tidak menawarkan banyak jalur. Kode yang memanggil API penyimpanan atau jaringan menangani kesalahan tersebut secara berbeda dari yang disebabkan oleh input yang salah atau keadaan internal yang tidak terduga. Kode saya melakukan salah satu dari ini jauh lebih sering daripada return err :

   • log. Fatal()
   • panic() untuk kesalahan yang seharusnya tidak pernah muncul
   • log pesan dan coba lagi

@gopherbot tambahkan Go2, LanguageChange

Bagaimana kalau hanya menggunakan ? untuk membuka hasil seperti rust

Alasan kami ragu untuk memanggil try() mungkin karena dua ikatan implisit. Kami tidak dapat melihat pengikatan untuk kesalahan nilai pengembalian dan argumen untuk try(). Untuk tentang try(), kita dapat membuat aturan bahwa kita harus menggunakan try() dengan fungsi argumen yang memiliki kesalahan dalam mengembalikan nilai. Tetapi mengikat untuk mengembalikan nilai tidak. Jadi saya pikir lebih banyak ekspresi diperlukan bagi pengguna untuk memahami apa yang dilakukan kode ini.

func doSomething() (int, %error) {
  f := try(foo())
  ...
}

• Kami tidak dapat menggunakan try() jika doSomething tidak memiliki nilai kembalian %error .
• Kami tidak dapat menggunakan try() jika foo() tidak memiliki kesalahan pada nilai pengembalian terakhir.

Sulit untuk menambahkan persyaratan/fitur baru ke sintaks yang ada.

Sejujurnya, saya pikir foo() juga harus memiliki %error.

Tambahkan 1 aturan lagi

• %error hanya dapat menjadi satu dalam daftar nilai kembalian suatu fungsi.

Dalam dokumen desain terperinci saya perhatikan bahwa dalam iterasi sebelumnya disarankan untuk meneruskan penangan kesalahan ke fungsi try builtin. Seperti ini:

handler := func(err error) error {
        return fmt.Errorf("foo failed: %v", err)  // wrap error
}

f := try(os.Open(filename), handler)  

atau bahkan lebih baik, seperti ini:

f := try(os.Open(filename), func(err error) error {
        return fmt.Errorf("foo failed: %v", err)  // wrap error
})  

Meskipun, seperti yang dinyatakan dokumen, bahwa ini menimbulkan beberapa pertanyaan, saya pikir proposal ini akan jauh lebih diinginkan dan berguna jika tetap mempertahankan kemungkinan ini untuk secara opsional menentukan fungsi atau penutupan penangan kesalahan seperti itu.

Kedua, saya tidak keberatan bahwa bawaan yang dapat menyebabkan fungsi kembali, tetapi, untuk sedikit bersepeda, nama 'coba' terlalu pendek untuk menunjukkan bahwa itu dapat menyebabkan pengembalian. Jadi nama yang lebih panjang, seperti attempt tampaknya lebih baik bagi saya.

EDIT: Ketiga, idealnya, bahasa go harus mendapatkan obat generik terlebih dahulu, di mana kasus penggunaan yang penting adalah kemampuan untuk mengimplementasikan fungsi coba ini sebagai generik, sehingga pelepasan sepeda dapat berakhir, dan semua orang bisa mendapatkan penanganan kesalahan yang mereka sukai.

Berita peretas memiliki beberapa poin: try tidak berperilaku seperti fungsi normal (dapat kembali) sehingga tidak baik untuk memberikan sintaks seperti fungsi. Sintaks return atau defer akan lebih tepat:

func CopyFile(src, dst string) (err error) {
        r := try os.Open(src)
        defer r.Close()

        w := try os.Create(dst)
        defer func() {
                w.Close()
                if err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        try io.Copy(w, r)
        try w.Close()
        return nil
}

@sheerun argumen tandingan umum untuk ini adalah bahwa panic juga merupakan fungsi bawaan yang mengubah aliran kontrol. Saya pribadi tidak setuju dengan itu, namun itu benar.

1. Menggemakan @deanveloper di atas , serta komentar serupa lainnya, saya sangat khawatir kami meremehkan biaya penambahan yang baru, agak halus, dan—terutama ketika dimasukkan dalam panggilan fungsi lain—kata kunci yang mudah diabaikan yang mengelola kontrol tumpukan panggilan mengalir. panic(...) adalah pengecualian yang relatif jelas (permainan kata-kata tidak dimaksudkan) untuk aturan bahwa return adalah satu-satunya jalan keluar dari suatu fungsi. Saya tidak berpikir kita harus menggunakan keberadaannya sebagai pembenaran untuk menambahkan yang ketiga.
2. Proposal ini akan mengkanonisasi pengembalian kesalahan yang tidak terbungkus sebagai perilaku default, dan menghapus kesalahan pembungkusan sebagai sesuatu yang Anda harus ikut serta, dengan upacara tambahan. Tapi, dalam pengalaman saya, itu justru mundur ke praktik yang baik. Saya berharap proposal di ruang ini akan mempermudah, atau setidaknya tidak lebih sulit, untuk menambahkan informasi kontekstual ke kesalahan di situs kesalahan.

mungkin kita bisa menambahkan varian dengan fungsi tambahan opsional seperti tryf dengan semantik ini:

func tryf(t1 T1, t1 T2, … tn Tn, te error, fn func(error) error) (T1, T2, … Tn)

terjemahkan ini

x1, x2, … xn = tryf(f(), func(err error) { return fmt.Errorf("foobar: %q", err) })

ke dalam ini

t1, … tn, te := f()
if te != nil {
    if fn != nil {
        te = fn(te)
    }
    err = te
    return
}

karena ini adalah pilihan eksplisit (daripada menggunakan try ) kita dapat menemukan jawaban yang masuk akal atas pertanyaan-pertanyaan dalam versi sebelumnya dari desain ini. misalnya jika fungsi augmentasi nihil, jangan lakukan apa-apa dan kembalikan saja kesalahan aslinya.

Saya khawatir try akan menggantikan penanganan kesalahan tradisional, dan akibatnya membuat anotasi jalur kesalahan menjadi lebih sulit.

Kode yang menangani kesalahan dengan mencatat pesan dan memperbarui penghitung telemetri akan dianggap cacat atau tidak tepat oleh linter dan pengembang yang mengharapkan try semuanya.

a, b, err := doWork()
if err != nil {
  updateCounters()
  writeLogs()
  return err
}

Go adalah bahasa yang sangat sosial dengan idiom umum yang ditegakkan oleh perkakas (fmt, lint, dll). Harap ingat konsekuensi sosial dari ide ini - akan ada kecenderungan untuk ingin menggunakannya di mana-mana.

@politician , maaf, tapi kata yang kamu cari bukan _social_ tapi _opinionated_. Go adalah bahasa pemrograman berpendirian. Selebihnya, saya sebagian besar setuju dengan apa yang Anda maksud.

Alat komunitas @beoran seperti Godep dan berbagai linter menunjukkan bahwa Go memiliki opini dan sosial, dan banyak drama dengan bahasa tersebut berasal dari kombinasi itu. Semoga kita berdua bisa sepakat bahwa try seharusnya tidak menjadi drama selanjutnya.

@politician Terima kasih atas klarifikasinya, saya tidak mengerti seperti itu. Saya tentu setuju bahwa kita harus berusaha menghindari drama.

Saya bingung tentang hal itu.

Dari blog: Kesalahan adalah nilai , dari sudut pandang saya, itu dirancang untuk dihargai bukan untuk diabaikan.

Dan saya percaya apa yang dikatakan Rop Pike, "Nilai dapat diprogram, dan karena kesalahan adalah nilai, kesalahan dapat diprogram.".

Kita tidak boleh menganggap error sebagai exception , ini seperti mengimpor kompleksitas tidak hanya untuk berpikir tetapi juga untuk pengkodean jika kita melakukannya.

"Gunakan bahasa untuk menyederhanakan penanganan kesalahan Anda." --Rob Pike

Dan lebih banyak lagi, kita dapat meninjau slide ini

Satu situasi di mana saya menemukan pemeriksaan kesalahan melalui if sangat canggung adalah ketika menutup file (misalnya pada NFS). Saya kira, saat ini kita dimaksudkan untuk menulis yang berikut, jika kesalahan kembali dari .Close() mungkin?

r, err := os.Open(src)
if err != nil {
    return err
}
defer func() {
    // maybe check whether a previous error occured?
    return r.Close()
}()

Bisakah defer try(r.Close()) menjadi cara yang baik untuk memiliki sintaks yang dapat dikelola untuk beberapa cara menangani kesalahan seperti itu? Setidaknya, masuk akal untuk menyesuaikan contoh CopyFile() dalam proposal dalam beberapa cara, untuk tidak mengabaikan kesalahan dari r.Close() dan w.Close() .

@seehuhn Contoh Anda tidak akan dikompilasi karena fungsi yang ditangguhkan tidak memiliki tipe pengembalian.

func doWork() (err error) {
  r, err := os.Open(src)
  if err != nil {
    return err
  }
  defer func() {
    err = r.Close()  // overwrite the return value
  }()
}

Akan bekerja seperti yang Anda harapkan. Kuncinya adalah nilai pengembalian bernama.

Saya suka proposalnya tetapi saya pikir contoh @seehuhn harus ditangani juga:

defer try(w.Close())

akan mengembalikan kesalahan dari Close() hanya jika kesalahan belum disetel.
Pola ini sering digunakan...

Saya setuju dengan kekhawatiran tentang menambahkan konteks ke kesalahan. Saya melihatnya sebagai salah satu praktik terbaik yang membuat pesan kesalahan lebih ramah (dan jelas) dan membuat proses debug lebih mudah.

Hal pertama yang saya pikirkan adalah mengganti fmt.HandleErrorf dengan fungsi tryf , yang mengawali kesalahan dengan konteks tambahan.

func tryf(t1 T1, t1 T2, … tn Tn, te error, ts string) (T1, T2, … Tn)

Misalnya (dari kode nyata yang saya miliki):

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil {
        return nil, errors.WithMessage(err, "load config dir")
    }
    b := bytes.NewBuffer(nil)
    if err = templates.ExecuteTemplate(b, "main", c); err != nil {
        return nil, errors.WithMessage(err, "execute main template")
    }
    buf, err := format.Source(b.Bytes())
    if err != nil {
        return nil, errors.WithMessage(err, "format main template")
    }
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    if err := ioutil.WriteFile(target, buf, 0644); err != nil {
        return nil, errors.WithMessagef(err, "write file %s", target)
    }
    // ...
}

Dapat diubah menjadi sesuatu seperti:

func (c *Config) Build() error {
    pkgPath := tryf(c.load(), "load config dir")
    b := bytes.NewBuffer(nil)
    tryf(emplates.ExecuteTemplate(b, "main", c), "execute main template")
    buf := tryf(format.Source(b.Bytes()), "format main template")
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    tryf(ioutil.WriteFile(target, buf, 0644), fmt.Sprintf("write file %s", target))
    // ...
}

Atau, jika saya mengambil contoh @agnivade :

func (p *pgStore) DoWork() (err error) {
    tx := tryf(p.handle.Begin(), "begin transaction")
        defer func() {
        if err != nil {
            tx.Rollback()
        }
    }()
    var res int64
    tryf(tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res), "insert table")
    _, = tryf(tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res), "insert table2")
    return tryf(tx.Commit(), "commit transaction")
}

Namun, @josharian mengangkat poin bagus yang membuat saya ragu dengan solusi ini:

Namun, seperti yang tertulis, ini memindahkan pemformatan gaya fmt dari sebuah paket ke dalam bahasa itu sendiri, yang membuka sekaleng worm.

Saya sepenuhnya setuju dengan proposal ini dan dapat melihat manfaatnya di sejumlah contoh.

Satu-satunya perhatian saya dengan proposal adalah penamaan try , saya merasa bahwa konotasinya dengan bahasa lain, dapat mengubah persepsi pengembang tentang apa tujuannya ketika berasal dari bahasa lain. Java datang untuk menemukan di sini.

Bagi saya, saya lebih suka builtin disebut pass . Saya merasa ini memberikan representasi yang lebih baik dari apa yang terjadi. Lagi pula, Anda tidak menangani kesalahan - alih-alih meneruskannya kembali untuk ditangani oleh penelepon. try memberikan kesan bahwa kesalahan telah ditangani.

Ini adalah jempol ke bawah dari saya, terutama karena masalah yang ingin diatasi ("pernyataan boilerplate jika biasanya terkait dengan penanganan kesalahan") sama sekali bukan masalah bagi saya. Jika semua pemeriksaan kesalahan hanya if err != nil { return err } maka saya dapat melihat beberapa nilai dalam menambahkan gula sintaksis untuk itu (meskipun Go adalah bahasa yang relatif bebas gula berdasarkan kecenderungan).

Faktanya, apa yang ingin saya lakukan jika terjadi kesalahan non-nihil sangat bervariasi dari satu situasi ke situasi berikutnya. Mungkin saya ingin t.Fatal(err) . Mungkin saya ingin menambahkan pesan dekorasi return fmt.Sprintf("oh no: %v", err) . Mungkin saya hanya mencatat kesalahan dan melanjutkan. Mungkin saya menetapkan tanda kesalahan pada objek SafeWriter saya dan melanjutkan, memeriksa tanda di akhir beberapa urutan operasi. Mungkin saya perlu mengambil tindakan lain. Tak satu pun dari ini dapat diotomatisasi dengan try . Jadi jika argumen untuk try adalah bahwa itu akan menghilangkan semua blok if err != nil , argumen itu tidak berlaku.

Apakah akan menghilangkan _some_ dari mereka? Tentu. Apakah itu tawaran yang menarik bagi saya? meh Aku benar-benar tidak peduli. Bagi saya, if err != nil hanyalah bagian dari Go, seperti kurung kurawal, atau defer . Saya mengerti itu terlihat bertele-tele dan berulang-ulang bagi orang yang baru menggunakan Go, tetapi orang yang baru menggunakan Go tidak cocok untuk membuat perubahan dramatis pada bahasa, karena banyak alasan.

Batasan untuk perubahan signifikan pada Go secara tradisional adalah bahwa perubahan yang diusulkan harus menyelesaikan masalah yang (A) signifikan, (B) mempengaruhi banyak orang, dan (C) diselesaikan dengan baik oleh proposal tersebut. Saya tidak yakin dengan salah satu dari tiga kriteria ini. Saya cukup senang dengan penanganan kesalahan Go apa adanya.

Untuk menggemakan @peterbourgon dan @deanveloper , salah satu hal favorit saya tentang Go adalah aliran kodenya jelas dan panic() tidak diperlakukan seperti mekanisme kontrol aliran standar seperti di Python.

Mengenai perdebatan tentang panic, panic() hampir selalu muncul dengan sendirinya pada sebuah baris karena tidak memiliki nilai. Anda tidak bisa fmt.Println(panic("oops")) . Ini sangat meningkatkan visibilitasnya dan membuatnya jauh lebih sedikit dibandingkan dengan try() daripada yang dibuat orang.

Jika ada konstruksi kontrol aliran lain untuk fungsi, saya akan _far_ lebih suka bahwa itu menjadi pernyataan yang dijamin sebagai item paling kiri pada sebuah baris.

Salah satu contoh dalam proposal membuat masalah bagi saya:

func printSum(a, b string) error {
        fmt.Println(
                "result:",
                try(strconv.Atoi(a)) + try(strconv.Atoi(b)),
        )
        return nil
}

Aliran kontrol benar-benar menjadi kurang jelas dan sangat kabur.

Ini juga bertentangan dengan niat awal Rob Pike bahwa semua kesalahan perlu ditangani secara eksplisit.

Sementara reaksi terhadap ini dapat berupa "maka jangan gunakan", masalahnya adalah -- perpustakaan lain akan menggunakannya, dan men-debug mereka, membacanya, dan menggunakannya, menjadi lebih bermasalah. Ini akan memotivasi perusahaan saya untuk tidak pernah mengadopsi go 2, dan mulai menggunakan hanya perpustakaan yang tidak menggunakan try . Jika saya tidak sendirian dengan ini, ini mungkin mengarah ke divisi a-la python 2/3.

Juga, penamaan try akan secara otomatis menyiratkan bahwa pada akhirnya catch akan muncul di sintaks, dan kita akan kembali menjadi Java.

Jadi, karena semua ini, saya _sangat_ menentang proposal ini.

Saya tidak suka nama try . Ini menyiratkan _percobaan_ dalam melakukan sesuatu dengan risiko kegagalan yang tinggi (saya mungkin memiliki bias budaya terhadap _try_ karena saya bukan penutur asli bahasa Inggris), sedangkan try akan digunakan jika kami mengharapkan kegagalan yang jarang terjadi (motivasi karena ingin mengurangi verbositas penanganan kesalahan) dan optimis. Selain itu try dalam proposal ini sebenarnya _catches_ kesalahan untuk mengembalikannya lebih awal. Saya suka saran pass dari @HiImJC.

Selain namanya, saya merasa canggung memiliki return -pernyataan seperti sekarang tersembunyi di tengah ekspresi. Ini merusak gaya aliran Go. Ini akan membuat tinjauan kode lebih sulit.

Secara umum, saya menemukan bahwa proposal ini hanya akan bermanfaat bagi pemrogram malas yang sekarang memiliki senjata untuk kode yang lebih pendek dan bahkan lebih sedikit alasan untuk melakukan upaya membungkus kesalahan. Karena itu juga akan membuat tinjauan lebih sulit (kembali di tengah ekspresi), saya pikir proposal ini bertentangan dengan tujuan "pemrograman pada skala" dari Go.

Salah satu hal favorit saya tentang Go yang biasanya saya katakan ketika menjelaskan bahasanya adalah bahwa hanya ada satu cara untuk melakukan sesuatu, untuk sebagian besar hal. Proposal ini sedikit bertentangan dengan prinsip itu dengan menawarkan banyak cara untuk melakukan hal yang sama. Saya pribadi berpikir ini tidak perlu dan itu akan menghilangkan, daripada menambah kesederhanaan dan keterbacaan bahasa.

Saya suka proposal ini secara keseluruhan. Interaksi dengan defer tampaknya cukup untuk menyediakan cara ergonomis untuk mengembalikan kesalahan sambil juga menambahkan konteks tambahan. Meskipun akan lebih baik untuk mengatasi halangan yang ditunjukkan @josharian tentang cara memasukkan kesalahan asli ke dalam pesan kesalahan yang dibungkus.

Apa yang hilang adalah cara ergonomis untuk berinteraksi dengan proposal pemeriksaan kesalahan di atas meja. Saya percaya API harus sangat berhati-hati dalam jenis kesalahan apa yang mereka kembalikan, dan defaultnya mungkin "kesalahan yang dikembalikan tidak dapat diperiksa dengan cara apa pun". Maka akan mudah untuk pergi ke keadaan di mana kesalahan dapat diperiksa dengan cara yang tepat, seperti yang didokumentasikan oleh tanda tangan fungsi ("Ini melaporkan kesalahan jenis X dalam keadaan A dan kesalahan jenis Y dalam keadaan B").

Sayangnya, sampai sekarang, proposal ini membuat opsi yang paling ergonomis menjadi yang paling tidak diinginkan (bagi saya); membabi buta melewati jenis kesalahan sewenang-wenang. Saya pikir ini tidak diinginkan karena mendorong untuk tidak memikirkan jenis kesalahan yang Anda kembalikan dan bagaimana pengguna API Anda akan menggunakannya. Kenyamanan tambahan dari proposal ini tentu bagus, tetapi saya khawatir itu akan mendorong perilaku buruk karena kenyamanan yang dirasakan akan lebih besar daripada nilai yang dirasakan dari memikirkan dengan cermat tentang informasi kesalahan apa yang Anda berikan (atau bocorkan).

Sebuah bandaid akan terjadi jika kesalahan yang dikembalikan oleh try diubah menjadi kesalahan yang tidak "tidak dapat dibuka". Sayangnya ini memiliki kelemahan yang cukup parah juga, karena membuat defer tidak dapat memeriksa kesalahan itu sendiri. Selain itu mencegah penggunaan di mana try sebenarnya akan mengembalikan kesalahan dari jenis yang diinginkan (yaitu, kasus penggunaan di mana try digunakan dengan hati-hati daripada sembarangan).

Solusi lain adalah dengan menggunakan kembali gagasan (yang dibuang) memiliki argumen kedua opsional ke try untuk mendefinisikan/memasukkan daftar putih jenis kesalahan yang mungkin dikembalikan dari situs itu. Ini agak merepotkan karena kami memiliki dua cara berbeda untuk mendefinisikan "jenis kesalahan", baik menurut nilai ( io.EOF dll) atau menurut jenis ( *os.PathError , *exec.ExitError ). Sangat mudah untuk menentukan jenis kesalahan yang merupakan nilai sebagai argumen untuk suatu fungsi, tetapi lebih sulit untuk menentukan jenisnya. Tidak yakin bagaimana menangani itu, tetapi membuang ide di luar sana.

Masalah yang ditunjukkan @josharian dapat dihindari dengan menunda evaluasi err:

defer func() { fmt.HandleErrorf(&err, "oops: %v", err) }()

Tidak terlihat bagus, tetapi harus berhasil. Namun saya lebih suka jika ini dapat diatasi dengan menambahkan kata kerja/bendera pemformatan baru untuk penunjuk kesalahan, atau mungkin untuk petunjuk secara umum, yang mencetak nilai dereferensi seperti pada %v biasa. Untuk tujuan contoh, sebut saja %*v :

defer fmt.HandleErrorf(&err, "oops: %*v", &err)

Di samping halangan, saya pikir proposal ini terlihat menjanjikan, tetapi tampaknya penting untuk menjaga ergonomi menambahkan konteks kesalahan di cek.

Sunting:

Pendekatan lain adalah dengan membungkus penunjuk kesalahan dalam sebuah struct yang mengimplementasikan Stringer :

type wraperr struct{ err *error }
func (w wraperr) String() string { return (*w.err).Error() }

...

defer handleErrorf(&err, "oops: %v", wraperr{&err})

Beberapa hal dari sudut pandang saya. Mengapa kita begitu khawatir tentang menyimpan beberapa baris kode? Saya menganggap ini sejalan dengan fungsi Small yang dianggap berbahaya .

Selain itu saya menemukan bahwa proposal semacam itu akan menghapus tanggung jawab menangani kesalahan dengan benar untuk beberapa "keajaiban" yang saya khawatirkan hanya akan disalahgunakan dan mendorong kemalasan yang menghasilkan kode dan bug berkualitas buruk.

Proposal seperti yang dinyatakan juga memiliki sejumlah perilaku yang tidak jelas sehingga ini sudah bermasalah daripada _eksplisit_ ekstra ~3 baris yang lebih jelas.

Saat ini kami menggunakan pola penangguhan dengan hemat di rumah. Ada artikel di sini yang memiliki penerimaan yang sama ketika kami menulisnya - https://bet365techblog.com/better-error-handling-in-go

Namun, kami menggunakannya untuk mengantisipasi kemajuan proposal check / handle .

Periksa/tangani adalah pendekatan yang jauh lebih komprehensif untuk membuat penanganan kesalahan menjadi lebih ringkas. Blok handle -nya mempertahankan cakupan fungsi yang sama seperti yang didefinisikan di dalamnya, sedangkan pernyataan defer adalah konteks baru dengan jumlah, berapa pun, overhead. Ini tampaknya lebih sesuai dengan idiom go, karena jika Anda menginginkan perilaku "kembalikan saja kesalahan ketika itu terjadi" Anda dapat mendeklarasikannya secara eksplisit sebagai handle { return err } .

Penundaan jelas bergantung pada referensi err yang dipertahankan juga, tetapi kami telah melihat masalah muncul dari membayangi referensi kesalahan dengan blok cakupan vars. Jadi itu bukan bukti yang cukup bodoh untuk dianggap sebagai cara standar untuk menangani kesalahan saat berjalan.

try , dalam contoh ini, tampaknya tidak menyelesaikan terlalu banyak dan saya memiliki ketakutan yang sama seperti yang lain bahwa itu hanya akan mengarah pada implementasi yang malas, atau yang menggunakan pola penangguhan secara berlebihan.

Jika penanganan kesalahan berbasis penangguhan akan menjadi A Thing, maka sesuatu seperti ini mungkin harus ditambahkan ke paket kesalahan:

        f := try(os.Create(filename))
        defer errors.Deferred(&err, f.Close)

Mengabaikan kesalahan pernyataan Tutup yang ditangguhkan adalah masalah yang cukup umum. Harus ada alat standar untuk membantunya.

Fungsi bawaan yang mengembalikan adalah penjualan yang lebih sulit daripada kata kunci yang melakukan hal yang sama.
Saya lebih suka jika itu adalah kata kunci seperti di Zig[1].

1. https://ziglang.org/documentation/master/#try

Fungsi bawaan, yang tanda tangan tipenya tidak dapat diekspresikan menggunakan sistem tipe bahasa, dan perilakunya yang mengacaukan fungsi biasanya, tampak seperti pintu keluar yang dapat digunakan berulang kali untuk menghindari evolusi bahasa yang sebenarnya.

Kami terbiasa segera mengenali pernyataan balik (dan panik) karena begitulah aliran kontrol semacam ini diekspresikan dalam Go (dan banyak bahasa lainnya). Tampaknya tidak terlalu jauh bahwa kita juga akan mengenali try sebagai aliran kontrol yang berubah setelah terbiasa, seperti yang kita lakukan untuk pengembalian. Saya tidak ragu bahwa dukungan IDE yang baik akan membantu dalam hal ini juga.

Saya pikir itu cukup mengada-ada. Dalam kode gofmt'ed, pengembalian selalu cocok dengan /^\t*return / – ini adalah pola yang sangat sepele untuk dilihat, tanpa bantuan apa pun. try , di sisi lain, dapat terjadi di mana saja dalam kode, bersarang secara sewenang-wenang jauh di dalam panggilan fungsi. Tidak ada jumlah pelatihan yang akan membuat kita dapat segera melihat semua aliran kontrol dalam suatu fungsi tanpa bantuan alat.

Lebih lanjut, fitur yang bergantung pada "dukungan IDE yang baik" akan merugikan di semua lingkungan di mana tidak ada dukungan IDE yang baik. Alat peninjauan kode langsung muncul di benak saya – akankah Gerrit menyoroti semua percobaan untuk saya? Bagaimana dengan orang yang memilih untuk tidak menggunakan IDE, atau penyorotan kode yang mewah, karena berbagai alasan? Akankah acme mulai menyoroti try ?

Fitur bahasa harus mudah dipahami dengan sendirinya, tidak bergantung pada dukungan editor.

@kungfusheep saya suka artikel itu. Merawat pembungkus dalam penangguhan saja sudah meningkatkan keterbacaan sedikit tanpa try .

Saya di kamp yang tidak merasa kesalahan dalam Go benar-benar masalah. Meski begitu, if err != nil { return err } bisa menjadi sangat gagap pada beberapa fungsi. Saya telah menulis fungsi yang memerlukan pemeriksaan kesalahan setelah hampir setiap pernyataan dan tidak ada yang memerlukan penanganan khusus selain membungkus dan mengembalikan. Terkadang tidak ada struct Buffer pintar yang akan membuat segalanya lebih baik. Terkadang itu hanya langkah kritis yang berbeda demi satu dan Anda hanya perlu melakukan hubungan pendek jika terjadi kesalahan.

Meskipun try pasti akan membuat kode itu jauh lebih mudah dibaca lebih baik saat sepenuhnya kompatibel, saya setuju bahwa try bukan fitur yang harus dimiliki, jadi jika orang terlalu takut mungkin lebih baik tidak memilikinya.

Semantiknya cukup jelas. Setiap kali Anda melihat try itu mengikuti jalur bahagia, atau kembali. Saya benar-benar tidak bisa lebih sederhana dari itu.

Ini terlihat seperti makro berselubung khusus.

@dominikh try selalu cocok dengan /try\(/ jadi saya tidak tahu apa maksud Anda sebenarnya. Ini sama-sama dapat dicari dan setiap editor yang pernah saya dengar memiliki fitur pencarian.

@qrpnxz Saya pikir poin yang dia coba sampaikan bukanlah bahwa Anda tidak dapat mencarinya secara terprogram, tetapi lebih sulit untuk mencari dengan mata Anda. Regexp hanyalah analogi, dengan penekanan pada /^\t* , menandakan bahwa semua pengembalian jelas menonjol dengan berada di awal baris (mengabaikan spasi putih di depan).

Memikirkannya lagi, seharusnya ada beberapa fungsi pembantu yang umum. Mungkin mereka harus dalam paket yang disebut "ditangguhkan".

Mengatasi proposal untuk check dengan format untuk menghindari penamaan pengembalian, Anda bisa melakukannya dengan fungsi yang memeriksa nil, seperti itu

func Format(err error, message string, args ...interface{}) error {
    if err == nil {
        return nil
    }
    return fmt.Errorf(...)
}

Ini dapat digunakan tanpa pengembalian bernama seperti:

func foo(s string) (int, error) {
    n, err := strconv.Atoi(s)
    try(deferred.Format(err, "bad string %q", s))
    return n, nil
}

fmt.HandleError yang diusulkan dapat dimasukkan ke dalam paket yang ditangguhkan sebagai gantinya dan fungsi pembantu error.Defer saya dapat disebut deferred.Exec dan mungkin ada exec bersyarat untuk prosedur yang dijalankan hanya jika kesalahannya bukan nol.

Menyatukannya, Anda mendapatkan sesuatu seperti

func CopyFile(src, dst string) (err error) {
    defer deferred.Annotate(&err, "copy %s %s", src, dst)

    r := try(os.Open(src))
    defer deferred.Exec(&err, r.Close)

    w := try(os.Create(dst))
    defer deferred.Exec(&err, r.Close)

    defer deferred.Cond(&err, func(){ os.Remove(dst) })
    try(io.Copy(w, r))

    return nil
}

Contoh lain:

func (p *pgStore) DoWork() (err error) {
    tx := try(p.handle.Begin())

    defer deferred.Cond(&err, func(){ tx.Rollback() })

    var res int64 
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    try(deferred.Format(err, "insert table")

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    try(deferred.Format(err, "insert table2"))

    return tx.Commit()
}

Proposal ini membawa kita dari memiliki if err != nil di mana-mana, menjadi memiliki try di mana-mana. Ini menggeser masalah yang diusulkan dan tidak menyelesaikannya.

Meskipun, saya berpendapat bahwa mekanisme penanganan kesalahan saat ini bukanlah masalah untuk memulai. Kami hanya perlu meningkatkan perkakas dan memeriksanya .

Selanjutnya, saya berpendapat bahwa if err != nil sebenarnya lebih mudah dibaca daripada try karena tidak mengacaukan garis bahasa logika bisnis, melainkan berada tepat di bawahnya:

file := try(os.OpenFile("thing")) // less readable than, 

file, err := os.OpenFile("thing")
if err != nil {

}

Dan jika Go ingin lebih ajaib dalam penanganan kesalahannya, mengapa tidak memilikinya sepenuhnya. Misalnya Go dapat secara implisit memanggil try jika pengguna tidak menetapkan kesalahan. Sebagai contoh:

func getString() (string, error) { ... }

func caller() {
  defer func() {
    if err != nil { ... } // whether `err` must be defined or not is not shown in this example. 
  }

  // would call try internally, because a user is not 
  // assigning an error value. Also, it can add a compile error
  // for "defined and not used err value" if the user does not 
  // handle the error. 
  str := getString()
}

Bagi saya, itu benar-benar akan menyelesaikan masalah redundansi dengan mengorbankan sihir dan potensi keterbacaan.

Oleh karena itu, saya mengusulkan agar kami benar-benar menyelesaikan 'masalah' seperti pada contoh di atas atau mempertahankan penanganan kesalahan saat ini tetapi alih-alih mengubah bahasa untuk menyelesaikan redundansi dan pembungkusan, kami tidak mengubah bahasa tetapi kami meningkatkan perkakas dan pemeriksaan kode untuk membuat pengalaman lebih baik.

Misalnya, di VSCode ada cuplikan bernama iferr jika Anda mengetiknya dan menekan enter, itu berkembang menjadi pernyataan penanganan kesalahan penuh ... oleh karena itu, menulisnya tidak pernah terasa melelahkan bagi saya, dan membaca nanti lebih baik .

@josharian

Meskipun ini bukan "perubahan pustaka sederhana", kami dapat mempertimbangkan untuk menerima kesalahan func main() juga.

Masalahnya adalah tidak semua platform memiliki semantik yang jelas tentang apa artinya itu. Penulisan ulang Anda bekerja dengan baik di program Go "tradisional" yang berjalan pada sistem operasi lengkap - tetapi segera setelah Anda menulis firmware mikrokontroler atau bahkan hanya WebAssembly, tidak terlalu jelas apa arti os.Exit(1) . Saat ini, os.Exit adalah panggilan perpustakaan, jadi implementasi Go gratis hanya untuk tidak menyediakannya. Bentuk main adalah masalah bahasa.

Pertanyaan tentang proposal yang mungkin paling baik dijawab oleh "tidak": Bagaimana try berinteraksi dengan argumen variadik? Ini adalah kasus pertama dari fungsi variadic (ish) yang tidak memiliki variadic-nes dalam argumen terakhir. Apakah ini diperbolehkan:

var e []error
try(e...)

Mengesampingkan mengapa Anda pernah melakukan itu. Saya menduga jawabannya adalah "tidak" (jika tidak, tindak lanjutnya adalah "bagaimana jika panjang irisan yang diperluas adalah 0). Cukup angkat sehingga dapat diingat ketika mengucapkan spesifikasi pada akhirnya.

• Beberapa fitur terbesar yang sedang berjalan adalah bawaan saat ini memastikan aliran kontrol yang jelas, penanganan kesalahan secara eksplisit dan dianjurkan, dan pengembang sangat dilarang menulis kode "ajaib". Proposal try tidak konsisten dengan prinsip dasar ini, karena akan mempromosikan steno dengan mengorbankan keterbacaan aliran kontrol.
• Jika proposal ini diadopsi, maka mungkin pertimbangkan untuk membuat pernyataan bawaan try alih-alih function . Maka itu lebih konsisten dengan pernyataan aliran kontrol lainnya seperti if . Selain itu, penghapusan tanda kurung bersarang sedikit meningkatkan keterbacaan.
• Sekali lagi, jika proposal diadopsi maka mungkin mengimplementasikannya tanpa menggunakan defer atau yang serupa. Itu sudah tidak dapat diimplementasikan dalam go murni (seperti yang ditunjukkan oleh orang lain) sehingga mungkin juga menggunakan implementasi yang lebih efisien di bawah tenda.

Saya melihat dua masalah dengan ini:

1. Ini menempatkan BANYAK kode bersarang di dalam fungsi. Itu menambah banyak beban kognitif ekstra, mencoba mengurai kode di kepala Anda.

1. Ini memberi kita tempat di mana kode dapat keluar dari tengah pernyataan.

Nomor 2 menurut saya jauh lebih buruk. Semua contoh di sini adalah panggilan sederhana yang mengembalikan kesalahan, tetapi yang lebih berbahaya adalah ini:

func doit(abc string) error {
    a := fmt.Sprintf("value of something: %s\n", try(getValue(abc)))
    log.Println(a)
    return nil
}

Kode ini dapat keluar di tengah sprintf itu, dan akan sangat mudah untuk melewatkan fakta itu.

Suara saya tidak. Ini tidak akan membuat kode go lebih baik. Itu tidak akan membuatnya lebih mudah untuk dibaca. Itu tidak akan membuatnya lebih kuat.

Saya sudah mengatakannya sebelumnya, dan proposal ini mencontohkannya - saya merasa 90% keluhan tentang Go adalah "Saya tidak ingin menulis pernyataan if atau loop" . Ini menghilangkan beberapa pernyataan if yang sangat sederhana, tetapi menambahkan beban kognitif dan memudahkan kehilangan titik keluar untuk suatu fungsi.

Saya hanya ingin menunjukkan bahwa Anda tidak dapat menggunakan ini di main dan mungkin membingungkan pengguna baru atau saat mengajar. Jelas ini berlaku untuk fungsi apa pun yang tidak mengembalikan kesalahan, tetapi saya pikir main itu istimewa karena muncul di banyak contoh..

func main() {
    f := try(os.Open("foo.txt"))
    defer f.Close()
}

Saya tidak yakin membuat try panic di main juga bisa diterima.

Selain itu tidak akan sangat berguna dalam tes ( func TestFoo(t* testing.T) ) yang sangat disayangkan :(

Masalah yang saya miliki dengan ini adalah mengasumsikan Anda selalu ingin mengembalikan kesalahan ketika itu terjadi. Kapan mungkin Anda ingin menambahkan konteks ke kesalahan dan mengembalikannya atau mungkin Anda hanya ingin berperilaku berbeda saat terjadi kesalahan. Mungkin itu tergantung pada jenis kesalahan yang dikembalikan.

Saya lebih suka sesuatu yang mirip dengan try/catch yang mungkin terlihat seperti

Dengan asumsi foo() didefinisikan sebagai

func foo() (int, error) {}

Anda kemudian bisa melakukannya

n := try(foo()) {
    case FirstError:
        // do something based on FirstError
    case OtherError:
        // do something based on OtherError
    default:
        // default behavior for any other error
}

Yang diterjemahkan menjadi

n, err := foo()
if errors.Is(err, FirstError) {
    // do something based on FirstError
if errors.Is(err, OtherError) {
    // do something based on OtherError
} else {
    // default behavior for any other error
}

Bagi saya, penanganan kesalahan adalah salah satu bagian terpenting dari basis kode.
Sudah terlalu banyak kode masuk if err != nil { return err } , mengembalikan kesalahan dari jauh di dalam tumpukan tanpa menambahkan konteks tambahan, atau bahkan (mungkin) lebih buruk menambahkan konteks dengan menutupi kesalahan yang mendasarinya dengan pembungkus fmt.Errorf .

Memberikan kata kunci baru yang merupakan jenis sihir yang tidak melakukan apa-apa selain mengganti if err != nil { return err } sepertinya merupakan jalan yang berbahaya untuk dilalui.
Sekarang semua kode hanya akan dibungkus dalam panggilan untuk mencoba. Ini agak bagus (meskipun keterbacaan menyebalkan) untuk kode yang hanya berurusan dengan kesalahan dalam paket seperti:

func foo() error {
  /// stuff
  try(bar())
  // more stuff
}

Tetapi saya berpendapat bahwa contoh yang diberikan benar-benar mengerikan dan pada dasarnya membuat penelepon mencoba memahami kesalahan yang sangat dalam di tumpukan, seperti penanganan pengecualian.
Tentu saja, ini semua terserah pengembang untuk melakukan hal yang benar di sini, tetapi ini memberi pengembang cara yang bagus untuk tidak peduli dengan kesalahan mereka dengan mungkin "kami akan memperbaikinya nanti" (dan kita semua tahu bagaimana kelanjutannya ).

Saya berharap kita akan melihat masalah dari perspektif yang berbeda dari *"bagaimana kita bisa mengurangi pengulangan" dan lebih banyak tentang "bagaimana kita bisa membuat penanganan kesalahan (yang tepat) lebih sederhana dan pengembang lebih produktif".
Kita harus memikirkan bagaimana ini akan memengaruhi menjalankan kode produksi.

*Catatan: Ini tidak benar-benar mengurangi pengulangan, hanya mengubah apa yang diulang, sambil membuat kode kurang terbaca karena semuanya terbungkus dalam try() .

Satu poin terakhir: Membaca proposal pada awalnya tampaknya bagus, kemudian Anda mulai masuk ke semua gotcha (setidaknya yang terdaftar) dan itu seperti "ok ya ini terlalu banyak".

Saya menyadari banyak dari ini subjektif, tapi itu sesuatu yang saya pedulikan. Semantik ini sangat penting.
Apa yang ingin saya lihat adalah cara untuk membuat penulisan dan pemeliharaan kode tingkat produksi lebih sederhana sehingga Anda mungkin juga melakukan kesalahan "benar" bahkan untuk kode tingkat POC/demo.

Karena konteks kesalahan tampaknya menjadi tema yang berulang...

Hipotesis: sebagian besar fungsi Go mengembalikan (T, error) sebagai lawan dari (T1, T2, T3, error)

Bagaimana jika, alih-alih mendefinisikan try sebagai try(T1, T2, T3, error) (T1, T2, T3) kita mendefinisikannya sebagai
try(func (args) (T1, T2, T3, error))(T1, T2, T3) ? (ini adalah perkiraan)

yang mengatakan bahwa struktur sintaksis dari panggilan try selalu merupakan argumen pertama yang merupakan ekspresi yang mengembalikan banyak nilai, yang terakhir adalah kesalahan.

Kemudian, seperti make , ini membuka pintu ke bentuk panggilan 2-argumen, di mana argumen kedua adalah konteks dari percobaan (misalnya string tetap, string dengan %v , fungsi yang mengambil argumen kesalahan dan mengembalikan kesalahan lain, dll.)

Ini masih memungkinkan rantai untuk kasing (T, error) tetapi Anda tidak dapat lagi menyambungkan beberapa pengembalian yang biasanya tidak diperlukan IMO.

@ cpuguy83 Jika Anda membaca proposal, Anda akan melihat tidak ada yang mencegah Anda membungkus kesalahan. Sebenarnya ada beberapa cara untuk melakukannya saat masih menggunakan try . Banyak orang tampaknya berasumsi bahwa untuk beberapa alasan sekalipun.

if err != nil { return err } sama dengan "kami akan memperbaikinya nanti" sebagai try kecuali lebih mengganggu saat membuat prototipe.

Saya tidak tahu bagaimana hal-hal yang ada di dalam sepasang tanda kurung kurang dapat dibaca daripada langkah-langkah fungsi yang juga setiap empat baris boilerplate.

Akan lebih baik jika Anda menunjukkan beberapa "gotcha" tertentu yang mengganggu Anda karena itulah topiknya.

Keterbacaan tampaknya menjadi masalah tetapi bagaimana dengan go fmt menghadirkan try() sehingga menonjol, seperti:

f := try(
    os.Open("file.txt")
)

@MrTravisB

Masalah yang saya miliki dengan ini adalah mengasumsikan Anda selalu ingin mengembalikan kesalahan ketika itu terjadi.

saya tidak setuju. Ini mengasumsikan bahwa Anda ingin melakukannya cukup sering untuk menjamin singkatan untuk hal itu. Jika tidak, itu tidak menghalangi penanganan kesalahan dengan jelas.

Kapan mungkin Anda ingin menambahkan konteks ke kesalahan dan mengembalikannya atau mungkin Anda hanya ingin berperilaku berbeda saat terjadi kesalahan.

Proposal menjelaskan pola untuk menambahkan konteks seluruh blok ke kesalahan. @josharian menunjukkan bahwa ada kesalahan dalam contoh, dan tidak jelas apa cara terbaik untuk menghindarinya. Saya telah menulis beberapa contoh cara untuk menanganinya.

Untuk konteks kesalahan yang lebih spesifik, sekali lagi, try melakukan sesuatu, dan jika Anda tidak menginginkannya, jangan gunakan try .

@boomlinde Persis poin saya. Proposal ini mencoba memecahkan kasus penggunaan tunggal daripada menyediakan alat untuk memecahkan masalah penanganan kesalahan yang lebih besar. Saya pikir pertanyaan mendasar jika persis apa yang Anda tunjukkan.

Ini mengasumsikan bahwa Anda ingin melakukannya cukup sering untuk menjamin singkatan untuk hal itu.

Menurut pendapat dan pengalaman saya, kasus penggunaan ini adalah minoritas kecil dan tidak memerlukan sintaks steno.

Juga, pendekatan menggunakan defer untuk menangani kesalahan memiliki masalah karena mengasumsikan Anda ingin menangani semua kemungkinan kesalahan dengan cara yang sama. Pernyataan defer tidak dapat dibatalkan.

defer fmt.HandleErrorf(&err, “foobar”)

n := try(foo())

x : try(foo2())

Bagaimana jika saya ingin penanganan kesalahan yang berbeda untuk kesalahan yang mungkin dikembalikan dari foo() vs foo2() ?

@MrTravisB

Bagaimana jika saya ingin penanganan kesalahan yang berbeda untuk kesalahan yang mungkin dikembalikan dari foo() vs foo2()?

Kemudian Anda menggunakan sesuatu yang lain. Itulah poin yang dibuat @boomlinde .

Mungkin Anda secara pribadi tidak sering melihat kasus penggunaan ini, tetapi banyak orang melihatnya, dan menambahkan try tidak terlalu memengaruhi Anda. Faktanya, semakin jarang kasus penggunaan bagi Anda, semakin sedikit hal itu mempengaruhi Anda bahwa try ditambahkan.

@qrpnxz

f := try(os.Open("/foo"))
data := try(ioutil.ReadAll(f))
try(send(data))

(ya saya mengerti ada ReadFile dan contoh khusus ini bukan cara terbaik untuk menyalin data di suatu tempat, bukan intinya)

Ini membutuhkan lebih banyak upaya untuk membaca karena Anda harus menguraikan inline try. Logika aplikasi dibungkus dalam panggilan lain.
Saya juga berpendapat bahwa penangan kesalahan defer di sini tidak akan baik kecuali hanya membungkus kesalahan dengan pesan baru... manusia untuk membaca apa yang terjadi.

Setidaknya operator adalah postfix ( ? ditambahkan ke akhir panggilan) yang tidak memberikan beban tambahan untuk menggali logika yang sebenarnya.

Kontrol aliran berbasis ekspresi

panic mungkin merupakan fungsi pengontrol aliran lainnya, tetapi tidak mengembalikan nilai, menjadikannya pernyataan yang efektif. Bandingkan ini dengan try , yang merupakan ekspresi dan dapat muncul di mana saja.

recover memang memiliki nilai dan mempengaruhi kontrol aliran, tetapi harus muncul dalam pernyataan defer . defer s ini biasanya literal fungsi, recover hanya dipanggil sekali, jadi recover juga muncul secara efektif sebagai pernyataan. Sekali lagi, bandingkan ini dengan try yang dapat terjadi di mana saja.

Saya pikir poin-poin itu berarti bahwa try membuatnya jauh lebih sulit untuk mengikuti aliran kontrol dengan cara yang belum pernah kita miliki sebelumnya, seperti yang telah ditunjukkan sebelumnya, tetapi saya tidak melihat perbedaan antara pernyataan dan ekspresi menunjukkan.

Usulan lain

Izinkan pernyataan seperti

if err != nil {
    return nil, 0, err
}

untuk diformat pada satu baris oleh gofmt ketika blok hanya berisi pernyataan return dan pernyataan itu tidak berisi baris baru. Sebagai contoh:

if err != nil { return nil, 0, err }

Alasan

• Itu tidak memerlukan perubahan bahasa
• Aturan pemformatannya sederhana dan jelas
• Aturan dapat dirancang untuk dipilih di mana gofmt menyimpan baris baru jika sudah ada (seperti struct literal). Keikutsertaan juga memungkinkan penulis untuk menekankan beberapa penanganan kesalahan
• Jika tidak ikut serta, kode dapat secara otomatis dipindahkan ke gaya baru dengan panggilan ke gofmt
• Ini hanya untuk pernyataan return , jadi tidak akan disalahgunakan untuk kode golf yang tidak perlu
• Berinteraksi dengan baik dengan komentar yang menjelaskan mengapa beberapa kesalahan dapat terjadi dan mengapa kesalahan tersebut dikembalikan. Menggunakan banyak ekspresi try bersarang menangani ini dengan buruk
• Ini mengurangi ruang vertikal penanganan kesalahan sebesar 66%
• Tidak ada aliran kontrol berbasis ekspresi
• Kode dibaca jauh lebih sering daripada yang tertulis, sehingga harus dioptimalkan untuk pembaca. Kode berulang yang memakan lebih sedikit ruang sangat membantu pembaca, di mana try lebih condong ke penulis
• Orang-orang telah mengusulkan try yang ada di beberapa baris. Misalnya komentar ini atau komentar ini yang memperkenalkan gaya seperti

f, err := os.Open(file)
try(maybeWrap(err))

• Gaya "coba pada barisnya sendiri" menghilangkan ambiguitas tentang nilai err yang dikembalikan. Oleh karena itu, saya menduga formulir ini akan umum digunakan. Mengizinkan satu baris jika blok hampir sama, kecuali itu juga eksplisit tentang apa nilai pengembaliannya
• Itu tidak mempromosikan penggunaan pengembalian bernama atau pembungkus berbasis defer yang tidak jelas. Keduanya meningkatkan penghalang untuk kesalahan pembungkusan dan yang pertama mungkin memerlukan godoc perubahan
• Tidak perlu ada diskusi tentang kapan harus menggunakan try versus menggunakan penanganan kesalahan tradisional
• Tidak menghalangi melakukan try atau sesuatu yang lain di masa depan. Perubahan mungkin positif bahkan jika try diterima
• Tidak ada interaksi negatif dengan fungsi testing atau main . Faktanya, jika proposal mengizinkan pernyataan bergaris tunggal apa pun alih-alih hanya mengembalikan, itu dapat mengurangi penggunaan pustaka berbasis pernyataan. Mempertimbangkan

value, err := something()
if err != nil { t.Fatal(err) }

• Tidak ada interaksi negatif dengan pemeriksaan terhadap kesalahan tertentu. Mempertimbangkan

n, err := src.Read(buf)
if err == io.EOF { return nil }
else if err != nil { return err }

Singkatnya, proposal ini memiliki biaya yang kecil, dapat dirancang untuk ikut serta, tidak menghalangi perubahan lebih lanjut karena hanya bergaya, dan mengurangi kesulitan membaca kode penanganan kesalahan verbose sambil menjaga semuanya tetap eksplisit. Saya pikir itu setidaknya harus dipertimbangkan sebagai langkah pertama sebelum masuk semua pada try .

Dari https://github.com/golang/go/issues/32437#issuecomment -498941435

Dengan mencoba

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        try(dbfile.RunMigrations(db, dbMigrations))
        t := &Thing{
                thingy:  thingy,
                scanner: try(newScanner(thingy, db, client)),
        }
        t.initOtherThing()
        return t, nil
}

Dengan ini

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        err := dbfile.RunMigrations(db, dbMigrations))
        if err != nil { return nil, fmt.Errorf("running migrations: %v", err) }

        t := &Thing{thingy: thingy}
        t.scanner, err = newScanner(thingy, db, client)
        if err != nil { return nil, fmt.Errorf("creating scanner: %v", err) }

        t.initOtherThing()
        return t, nil
}

Ini kompetitif dalam penggunaan ruang sambil tetap memungkinkan untuk menambahkan konteks ke kesalahan.

Dari https://github.com/golang/go/issues/32437#issuecomment -499007288

Dengan mencoba

func (c *Config) Build() error {
    pkgPath := try(c.load())
    b := bytes.NewBuffer(nil)
    try(emplates.ExecuteTemplate(b, "main", c))
    buf := try(format.Source(b.Bytes()))
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    try(ioutil.WriteFile(target, buf, 0644))
    // ...
}

Dengan ini

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil { return nil, errors.WithMessage(err, "load config dir") }

    b := bytes.NewBuffer(nil)
    err = templates.ExecuteTemplate(b, "main", c)
    if err != nil { return nil, errors.WithMessage(err, "execute main template") }

    buf, err := format.Source(b.Bytes())
    if err != nil { return nil, errors.WithMessage(err, "format main template") }

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    err = ioutil.WriteFile(target, buf, 0644)
    if err != nil { return nil, errors.WithMessagef(err, "write file %s", target) }
    // ...
}

Komentar asli menggunakan tryf hipotetis untuk melampirkan pemformatan, yang telah dihapus. Tidak jelas cara terbaik untuk menambahkan semua konteks yang berbeda, dan mungkin try bahkan tidak akan berlaku.

@cpuguy83
Bagi saya ini lebih mudah dibaca dengan try . Dalam contoh ini saya membaca "buka file, baca semua byte, kirim data". Dengan penanganan kesalahan biasa saya akan membaca "buka file, periksa apakah ada kesalahan, penanganan kesalahan melakukan ini, lalu baca semua byte, sekarang periksa apakah ada sesuatu yang terjadi..." Saya tahu Anda dapat memindai melalui err != nil s, tetapi bagi saya try lebih mudah karena ketika saya melihatnya saya langsung tahu perilakunya: return if err != nil. Jika Anda memiliki cabang, saya harus melihat apa fungsinya. Itu bisa melakukan apa saja.

Saya juga berpendapat bahwa penangguhan penangan kesalahan di sini tidak akan baik kecuali hanya membungkus kesalahan dengan pesan baru

Saya yakin ada hal lain yang dapat Anda lakukan di penangguhan, tetapi terlepas dari itu, try tetap untuk kasus umum sederhana. Kapan pun Anda ingin melakukan sesuatu yang lebih, selalu ada penanganan kesalahan Go yang baik. Itu tidak akan hilang.

@zeebo Ya, saya menyukainya.
Artikel @kungfusheep menggunakan pemeriksaan kesalahan satu baris seperti itu dan saya keluar untuk mencobanya. Kemudian segera setelah saya simpan, gofmt memperluasnya menjadi tiga baris yang menyedihkan. Banyak fungsi di stdlib didefinisikan dalam satu baris seperti itu sehingga saya terkejut bahwa gofmt akan memperluasnya.

@qrpnxz

Saya kebetulan membaca banyak kode go. Salah satu hal terbaik tentang bahasa ini adalah kemudahan yang berasal dari sebagian besar kode yang mengikuti gaya tertentu (terima kasih gofmt).
Saya tidak ingin membaca banyak kode yang dibungkus try(f()) .
Ini berarti akan ada perbedaan dalam gaya/praktik kode, atau linter seperti "oh Anda seharusnya menggunakan try() di sini" (yang lagi-lagi saya bahkan tidak suka, itulah poin saya dan orang lain berkomentar pada proposal ini).

Secara objektif tidak lebih baik dari if err != nil { return err } , hanya lebih sedikit untuk mengetik.

Satu hal terakhir:

Jika Anda membaca proposal, Anda akan melihat tidak ada yang mencegah Anda dari

Bisakah kita menahan diri dari bahasa seperti itu? Tentu saja saya membaca proposalnya. Kebetulan saya membacanya tadi malam dan kemudian berkomentar pagi ini setelah memikirkannya dan tidak menjelaskan hal-hal kecil dari apa yang saya maksudkan.
Ini adalah nada permusuhan yang luar biasa.

@cpuguy83
Orang cpu saya yang buruk. Aku tidak bermaksud seperti itu.

Dan saya kira Anda harus menunjukkan bahwa kode yang menggunakan try akan terlihat sangat berbeda dari kode yang tidak, jadi saya dapat membayangkan itu akan memengaruhi pengalaman menguraikan kode itu, tetapi saya tidak dapat sepenuhnya setuju bahwa perbedaan itu berarti lebih buruk dalam hal ini, meskipun saya mengerti Anda secara pribadi tidak menyukainya sama seperti saya pribadi menyukainya. Banyak hal di Go yang seperti itu. Mengenai apa yang linter suruh Anda lakukan adalah masalah lain sama sekali, saya pikir.

Tentu itu tidak secara objektif lebih baik. Saya mengungkapkan bahwa itu lebih mudah dibaca bagi saya . Saya dengan hati-hati mengatakan itu.

Sekali lagi, maaf karena terdengar seperti itu. Meskipun ini adalah argumen, saya tidak bermaksud memusuhi Anda.

https://github.com/golang/go/issues/32437#issuecomment -498908380

Tidak ada yang akan membuat Anda menggunakan try.

Mengabaikan glibness, saya pikir itu cara yang cukup bergelombang untuk mengabaikan kritik desain.

Tentu, saya tidak harus menggunakannya. Tetapi siapa pun yang saya gunakan untuk menulis kode dapat menggunakannya dan memaksa saya untuk mencoba menguraikan try(try(try(to()).parse().this)).easily()) . Ini seperti mengatakan

Tidak ada yang akan membuat Anda menggunakan antarmuka kosong{}.

Bagaimanapun, Go cukup ketat tentang kesederhanaan: gofmt membuat semua kode terlihat sama. Jalan bahagia terus ke kiri dan apa pun yang bisa mahal atau mengejutkan adalah eksplisit . try seperti yang diusulkan adalah perubahan 180 derajat dari ini. Kesederhanaan != ringkas.

Setidaknya try harus menjadi kata kunci dengan nilai.

Ini tidak _objectively_ lebih baik dari if err != nil { return err } , hanya lebih sedikit untuk mengetik.

Ada satu perbedaan objektif antara keduanya: try(Foo()) adalah ekspresi. Bagi sebagian orang, perbedaan itu adalah kerugian (kritik try(strconv.Atoi(x))+try(strconv.Atoi(y)) ). Bagi orang lain, perbedaan itu adalah keuntungan untuk alasan yang hampir sama. Masih tidak secara objektif lebih baik atau lebih buruk - tetapi saya juga tidak berpikir perbedaannya harus disapu di bawah karpet dan mengklaim bahwa itu "hanya kurang untuk mengetik" tidak melakukan keadilan proposal.

@elagergren-spideroak sulit untuk mengatakan bahwa try menjengkelkan untuk dilihat dalam satu napas dan kemudian mengatakan bahwa itu tidak eksplisit di napas berikutnya. Anda harus memilih satu.

adalah umum untuk melihat argumen fungsi dimasukkan ke dalam variabel sementara terlebih dahulu. Saya yakin itu akan lebih umum untuk dilihat

this := try(to()).parse().this
that := try(this.easily())

daripada contoh Anda.

try tidak melakukan apa-apa adalah jalan yang menyenangkan, sehingga terlihat seperti yang diharapkan. Di jalan yang tidak bahagia yang dilakukannya hanyalah kembali. Melihat ada try sudah cukup untuk mengumpulkan informasi itu. Tidak ada yang mahal tentang kembali dari suatu fungsi, jadi dari deskripsi itu saya tidak berpikir try melakukan 180

@josharian Mengenai komentar Anda di https://github.com/golang/go/issues/32437#issuecomment -498941854 , saya rasa tidak ada kesalahan evaluasi awal di sini.

defer fmt.HandleErrorf(&err, “foobar: %v”, err)

Nilai err yang tidak dimodifikasi diteruskan ke HandleErrorf , dan pointer ke err diteruskan. Kami memeriksa apakah err adalah nil (menggunakan pointer). Jika tidak, kami memformat string, menggunakan nilai err yang tidak dimodifikasi. Kemudian kita set err ke nilai kesalahan yang diformat, menggunakan pointer.

@Merovius Proposal sebenarnya hanyalah sintaks gula makro, jadi itu akan berakhir tentang apa yang menurut orang terlihat lebih bagus atau akan menyebabkan sedikit masalah. Jika menurut Anda tidak, tolong jelaskan kepada saya. Itu sebabnya saya mendukungnya, secara pribadi. Ini adalah tambahan yang bagus tanpa menambahkan kata kunci apa pun dari sudut pandang saya.

@ianlancetaylor , saya pikir @josharian benar: nilai "tidak dimodifikasi" dari err adalah nilai pada saat defer didorong ke tumpukan, bukan nilai (mungkin dimaksudkan) dari err ditetapkan oleh try sebelum kembali.

Masalah lain yang saya miliki dengan try adalah membuatnya lebih mudah bagi orang untuk membuang lebih banyak dan logika ke dalam satu baris. Ini adalah masalah utama saya dengan sebagian besar bahasa lain, adalah bahwa mereka membuatnya sangat mudah untuk menempatkan seperti 5 ekspresi dalam satu baris, dan saya tidak ingin itu pergi.

this := try(to()).parse().this
that := try(this.easily())

^^ bahkan ini benar-benar mengerikan. Baris pertama, saya harus melompat-lompat melakukan pencocokan paren di kepala saya. Bahkan baris kedua yang sebenarnya cukup sederhana... sangat sulit untuk dibaca.
Fungsi bersarang sulit dibaca.

parser, err := to()
if err != nil {
    return err
}
this := parser.parse().this
that, err := this.easily()
if err != nil {
    return err
}

^^ Ini jauh lebih mudah dan lebih baik IMO. Ini sangat sederhana dan jelas. ya, ini lebih banyak baris kode, saya tidak peduli. Ini sangat jelas.

@bcmils @josharian Ah, tentu saja, terima kasih. Jadi itu harus

defer func() { fmt.HandleErrorf(&err, “foobar: %v”, err) }()

Tidak begitu bagus. Mungkin fmt.HandleErrorf harus secara implisit meneruskan nilai kesalahan sebagai argumen terakhir.

Masalah ini mendapat banyak komentar dengan sangat cepat, dan banyak dari mereka yang menurut saya mengulangi komentar yang telah dibuat. Tentu saja jangan ragu untuk berkomentar, tetapi saya ingin dengan lembut menyarankan bahwa jika Anda ingin menyatakan kembali poin yang telah dibuat, Anda melakukannya dengan menggunakan emoji GitHub, daripada mengulangi poin tersebut. Terima kasih.

@ianlancetaylor jika fmt.HandleErrorf mengirimkan err sebagai argumen pertama setelah format maka implementasinya akan lebih baik dan pengguna akan dapat merujuknya dengan %[1]v selalu.

@natefinch Sangat setuju.

Saya ingin tahu apakah pendekatan gaya karat akan lebih cocok?
Perhatikan ini bukan proposal hanya memikirkannya ...

this := to()?.parse().this
that := this.easily()?

Pada akhirnya saya pikir ini lebih bagus, tetapi (bisa menggunakan ! atau yang lain juga ...), tetapi masih tidak memperbaiki masalah penanganan kesalahan dengan baik.

tentu saja karat juga memiliki try() kurang lebih seperti ini, tapi... gaya karat lainnya.

Ini tidak _objectively_ lebih baik dari if err != nil { return err } , hanya lebih sedikit untuk mengetik.

Ada satu perbedaan objektif antara keduanya: try(Foo()) adalah ekspresi. Bagi sebagian orang, perbedaan itu adalah kerugian (kritik try(strconv.Atoi(x))+try(strconv.Atoi(y)) ). Bagi orang lain, perbedaan itu adalah keuntungan untuk alasan yang hampir sama. Masih tidak secara objektif lebih baik atau lebih buruk - tetapi saya juga tidak berpikir perbedaannya harus disapu di bawah karpet dan mengklaim bahwa itu "hanya kurang untuk mengetik" tidak melakukan keadilan proposal.

Ini adalah salah satu alasan terbesar saya menyukai sintaks ini; itu memungkinkan saya menggunakan fungsi pengembalian kesalahan sebagai bagian dari ekspresi yang lebih besar tanpa harus menyebutkan semua hasil antara. Dalam beberapa situasi, memberi nama mereka mudah, tetapi di situasi lain tidak ada nama yang bermakna atau tidak berlebihan untuk diberikan kepada mereka, dalam hal ini saya lebih suka tidak memberi mereka nama sama sekali.

@MrTravisB

Persis poin saya. Proposal ini mencoba memecahkan kasus penggunaan tunggal daripada menyediakan alat untuk memecahkan masalah penanganan kesalahan yang lebih besar. Saya pikir pertanyaan mendasar jika persis apa yang Anda tunjukkan.

Apa yang saya katakan secara spesifik yang merupakan maksud Anda? Tampaknya bagi saya bahwa Anda pada dasarnya salah memahami maksud saya jika Anda berpikir bahwa kita setuju.

Menurut pendapat dan pengalaman saya, kasus penggunaan ini adalah minoritas kecil dan tidak memerlukan sintaks steno.

Di sumber Go ada ribuan kasus yang dapat ditangani oleh try di luar kotak meskipun tidak ada cara untuk menambahkan konteks ke kesalahan. Jika kecil, itu masih merupakan penyebab umum keluhan.

Juga, pendekatan menggunakan penangguhan untuk menangani kesalahan memiliki masalah karena mengasumsikan Anda ingin menangani semua kemungkinan kesalahan yang sama. pernyataan penangguhan tidak dapat dibatalkan.

Demikian pula, pendekatan menggunakan + untuk menangani aritmatika mengasumsikan bahwa Anda tidak ingin mengurangi, jadi Anda tidak ingin menguranginya. Pertanyaan yang menarik adalah apakah konteks kesalahan di seluruh blok setidaknya mewakili pola umum.

Bagaimana jika saya ingin penanganan kesalahan yang berbeda untuk kesalahan yang mungkin dikembalikan dari foo() vs foo2()

Sekali lagi, maka Anda tidak menggunakan try . Kemudian Anda tidak mendapatkan apa pun dari try , tetapi Anda juga tidak kehilangan apa pun.

@cpuguy83

Saya ingin tahu apakah pendekatan gaya karat akan lebih cocok?

Proposal menyajikan argumen menentang ini.

Pada titik ini, saya pikir memiliki try{}catch{} lebih mudah dibaca :upside_down_face:

1. Menggunakan impor bernama untuk berkeliling kasus sudut defer tidak hanya buruk untuk hal-hal seperti godoc, tetapi yang paling penting itu sangat rawan kesalahan. Saya tidak peduli saya bisa membungkus semuanya dengan func() lain untuk mengatasi masalah ini, hanya saja lebih banyak hal yang perlu saya ingat, saya pikir itu mendorong "praktik buruk".

2. Tidak ada yang akan membuat Anda menggunakan try.

   Itu tidak berarti itu adalah solusi yang baik, saya menunjukkan bahwa ide saat ini memiliki kekurangan dalam desain dan saya memintanya untuk ditangani dengan cara yang tidak terlalu rawan kesalahan.

3. Saya pikir contoh seperti try(try(try(to()).parse().this)).easily()) tidak realistis, ini sudah bisa dilakukan dengan fungsi lain dan saya pikir akan adil bagi mereka yang meninjau kode untuk memintanya untuk dibagi.

4. Bagaimana jika saya memiliki 3 tempat yang dapat error-out dan saya ingin membungkus setiap tempat secara terpisah? try() membuat ini sangat sulit, sebenarnya try() sudah mengecilkan kesalahan pembungkusan mengingat kesulitannya, tetapi berikut adalah contoh dari apa yang saya maksud:

   func before() error {
     x, err := foo()
     if err != nil {
       wrap(err, "error on foo")
     }
     y, err := bar(x)
     if err != nil {
       wrapf(err, "error on bar with x=%v", x)
     }
     fmt.Println(y)
     return nil
   }
   
   func after() (err error) {
     defer fmt.HandleErrorf(&err, "something failed but I don't know where: %v", err)
     x := try(foo())
     y := try(bar(x))
     fmt.Println(y)
     return nil
   }
   

5. Sekali lagi, maka Anda tidak menggunakan try . Kemudian Anda tidak mendapatkan apa pun dari try , tetapi Anda juga tidak kehilangan apa pun.

   Katakanlah itu praktik yang baik untuk membungkus kesalahan dengan konteks yang berguna, try() akan dianggap sebagai praktik yang buruk karena tidak menambahkan konteks apa pun. Ini berarti bahwa try() adalah fitur yang tidak ingin digunakan oleh siapa pun dan menjadi fitur yang sangat jarang digunakan sehingga mungkin juga tidak ada.

   Daripada hanya mengatakan "baiklah, jika Anda tidak menyukainya, jangan gunakan dan tutup mulut" (ini adalah bagaimana membaca), saya pikir akan lebih baik untuk mencoba untuk mengatasi apa yang banyak digunakan untuk mempertimbangkan cacat dalam desain. Bisakah kita mendiskusikan apa yang bisa dimodifikasi dari desain yang diusulkan sehingga masalah kita ditangani dengan cara yang lebih baik?

@boomlinde Poin yang kami setujui adalah bahwa proposal ini mencoba menyelesaikan kasus penggunaan kecil dan fakta bahwa "jika Anda tidak membutuhkannya, jangan gunakan itu" adalah argumen utama untuk itu. Seperti yang dinyatakan @elagergren-spideroak, argumen itu tidak berfungsi karena meskipun saya tidak ingin menggunakannya, orang lain akan memaksa saya untuk menggunakannya. Dengan logika argumen Anda, Go juga harus memiliki pernyataan ternary. Dan jika Anda tidak menyukai pernyataan ternary, jangan gunakan itu.

Penafian - Saya pikir Go harus memiliki pernyataan ternary tetapi mengingat bahwa pendekatan Go terhadap fitur bahasa adalah tidak memperkenalkan fitur yang dapat membuat kode lebih sulit dibaca maka seharusnya tidak.

Hal lain terjadi pada saya: Saya melihat banyak kritik berdasarkan gagasan bahwa memiliki try dapat mendorong pengembang untuk menangani kesalahan dengan sembarangan. Tapi menurut saya ini, jika ada, lebih benar dari bahasa saat ini; boilerplate penanganan kesalahan cukup mengganggu sehingga mendorong seseorang untuk menelan atau mengabaikan beberapa kesalahan untuk menghindarinya. Misalnya, saya telah menulis hal-hal seperti ini beberapa kali:

func exists(filename string) bool {
  _, err := os.Stat(filename)
  return err == nil
}

agar dapat menulis if exists(...) { ... } , meskipun kode ini secara diam-diam mengabaikan beberapa kemungkinan kesalahan. Jika saya memiliki try , saya mungkin tidak akan repot-repot melakukannya dan hanya mengembalikan (bool, error) .

Menjadi kacau di sini, saya akan melemparkan ide untuk menambahkan fungsi bawaan kedua yang disebut catch yang akan menerima fungsi yang mengambil kesalahan dan mengembalikan kesalahan yang ditimpa, kemudian jika catch berikutnya disebut itu akan menimpa pawang. Misalnya:

func catch(handler func(err error) error) {
  // .. impl ..
}

Sekarang, fungsi bawaan ini juga akan menjadi fungsi seperti makro yang akan menangani kesalahan berikutnya yang dikembalikan oleh try seperti ini:

func wrapf(format string, ...values interface{}) func(err error) error {
  // user defined
  return func(err error) error {
    return fmt.Errorf(format + ": %v", ...append(values, err))
  }
}
func sample() {
  catch(wrapf("something failed in foo"))
  try(foo()) // "something failed in foo: <error>"
  x := try(foo2()) // "something failed in foo: <error>"
  // Subsequent calls for catch overwrite the handler
  catch(wrapf("something failed in bar with x=%v", x))
  try(bar(x)) // "something failed in bar with x=-1: <error>"
}

Ini bagus karena saya bisa membungkus kesalahan tanpa defer yang bisa rawan kesalahan kecuali kita menggunakan nilai pengembalian bernama atau membungkus dengan fungsi lain, itu juga bagus karena defer akan menambahkan penangan kesalahan yang sama untuk semua kesalahan bahkan jika saya ingin menangani 2 di antaranya secara berbeda. Anda juga dapat menggunakannya sesuai keinginan Anda, misalnya:

func foo(a, b string) (int64, error) {
  return try(strconv.Atoi(a)) + try(strconv.Atoi(b))
}
func withContext(a, b string) (int64, error) {
  catch(func (err error) error {
    return fmt.Errorf("can't parse a: %s, b: %s, err: %v", a, b, err)
  })
  return try(strconv.Atoi(a)) + try(strconv.Atoi(b))
}
func moreExplicitContext(a, b string) (int64, error) {
  catch(func (err error) error {
    return fmt.Errorf("can't parse a: %s, err: %v", a, err)
  })
  x := try(strconv.Atoi(a))
  catch(func (err error) error {
    return fmt.Errorf("can't parse b: %s, err: %v", b, err)
  })
  y := try(strconv.Atoi(b))
  return x + y
}
func withHelperWrapf(a, b string) (int64, error) {
  catch(wrapf("can't parse a: %s", a))
  x := try(strconv.Atoi(a))
  catch(wrapf("can't parse b: %s", b))
  y := try(strconv.Atoi(b))
  return x + y
}
func before(a, b string) (int64, error) {
  x, err := strconv.Atoi(a)
  if err != nil {
    return 0,  fmt.Errorf("can't parse a: %s, err: %v", a, err)
  }
  y, err := strconv.Atoi(b)
  if err != nil {
    return 0,  fmt.Errorf("can't parse b: %s, err: %v", b, err)
  }
  return x + y
}

Dan masih dalam mood yang kacau (untuk membantu Anda berempati) Jika Anda tidak suka catch , Anda tidak perlu menggunakannya.

Sekarang... maksudku bukan kalimat terakhir, tapi rasanya kurang membantu untuk diskusi, IMO agresif sekali.
Namun, jika kita menempuh rute ini, saya pikir kita mungkin juga memiliki try{}catch(error err){} sebagai gantinya :stuck_out_tongue:

Lihat juga #27519 - model kesalahan #id/catch

Tidak ada yang akan membuat Anda menggunakan try.

Mengabaikan glibness, saya pikir itu cara yang cukup bergelombang untuk mengabaikan kritik desain.

Maaf, glib bukan maksud saya.

Apa yang saya coba katakan, adalah bahwa try tidak dimaksudkan sebagai solusi 100%. Ada berbagai paradigma penanganan kesalahan yang tidak ditangani dengan baik oleh try . Misalnya, jika Anda perlu menambahkan konteks yang bergantung pada situs panggilan ke kesalahan. Anda selalu dapat kembali menggunakan if err != nil { untuk menangani kasus yang lebih rumit tersebut.

Ini tentu saja merupakan argumen yang valid bahwa try tidak dapat menangani X, untuk berbagai contoh X. Tetapi seringkali menangani kasus X berarti membuat mekanisme menjadi lebih rumit. Ada tradeoff di sini, menangani X di satu sisi tetapi memperumit mekanisme untuk yang lainnya. Apa yang kita lakukan semua tergantung pada seberapa umum X itu, dan seberapa banyak kerumitan yang diperlukan untuk menangani X.

Jadi dengan "Tidak ada yang akan membuat Anda menggunakan try", maksud saya bahwa contoh yang dimaksud adalah di 10%, bukan 90%. Pernyataan itu tentu saja untuk diperdebatkan, dan saya senang mendengar argumen balasan. Tetapi pada akhirnya kita harus menarik garis di suatu tempat dan berkata "ya, try tidak akan menangani kasus itu. Anda harus menggunakan penanganan kesalahan gaya lama. Maaf.".

Bukannya "coba tidak dapat menangani kasus khusus penanganan kesalahan ini" itu masalahnya, itu "coba mendorong Anda untuk tidak membungkus kesalahan Anda". Ide check-handle memaksa Anda untuk menulis pernyataan pengembalian, jadi menulis pembungkus kesalahan cukup sepele.

Di bawah proposal ini Anda perlu menggunakan pengembalian bernama dengan defer , yang tidak intuitif dan tampaknya sangat retas.

Ide check-handle memaksa Anda untuk menulis pernyataan pengembalian, jadi menulis pembungkus kesalahan cukup sepele.

Itu tidak benar - dalam rancangan desain, setiap fungsi yang mengembalikan kesalahan memiliki penangan default yang hanya mengembalikan kesalahan.

Membangun poin nakal @Goodwine , Anda tidak benar-benar membutuhkan fungsi terpisah seperti HandleErrorf jika Anda memiliki fungsi jembatan tunggal seperti

func handler(err *error, handle func(error) error) {
  // nil handle is treated as the identity
  if *err != nil && handle != nil {
    *err = handle(*err)
  }
}

yang akan Anda gunakan seperti

defer handler(&err, func(err error) error {
  if errors.Is(err, io.EOF) {
    return nil
  }
  return fmt.Errorf("oops: %w", err)
})

Anda dapat menjadikan handler itu sendiri sebagai bawaan semi-ajaib seperti try .

Jika itu ajaib, itu bisa mengambil argumen pertamanya secara implisit—memungkinkannya untuk digunakan bahkan dalam fungsi yang tidak menyebutkan pengembalian error mereka, menghilangkan salah satu aspek yang kurang beruntung dari proposal saat ini sambil membuatnya kurang rewel dan rawan kesalahan untuk menghias kesalahan. Tentu saja, itu tidak mengurangi banyak contoh sebelumnya:

defer handler(func(err error) error {
  if errors.Is(err, io.EOF) {
    return nil
  }
  return fmt.Errorf("oops: %w", err)
})

Jika ajaib dengan cara ini, itu harus menjadi kesalahan waktu kompilasi jika digunakan di mana saja kecuali sebagai argumen untuk defer . Anda bisa melangkah lebih jauh dan membuatnya ditangguhkan secara implisit, tetapi defer handler terbaca dengan cukup baik.

Karena menggunakan defer ia dapat memanggil fungsi handle setiap kali ada kesalahan non-nil yang dikembalikan, membuatnya berguna bahkan tanpa try karena Anda dapat menambahkan

defer handler(wrapErrWithPackageName)

di atas untuk fmt.Errorf("mypkg: %w", err) semuanya.

Itu memberi Anda banyak proposal check / handle yang lebih lama tetapi itu berfungsi dengan penangguhan secara alami (dan secara eksplisit) sambil menghilangkan kebutuhan, dalam banyak kasus, untuk secara eksplisit menamai err kembali. Seperti try ini adalah makro yang relatif mudah yang (saya bayangkan) dapat diimplementasikan sepenuhnya di front end.

Itu tidak benar - dalam rancangan desain, setiap fungsi yang mengembalikan kesalahan memiliki penangan default yang hanya mengembalikan kesalahan.

Buruk saya, Anda benar.

Maksud saya, saya pikir contoh yang dimaksud ada di 10%, bukan 90%. Pernyataan itu tentu saja untuk diperdebatkan, dan saya senang mendengar argumen balasan. Tapi akhirnya kita harus menarik garis di suatu tempat dan berkata "ya, coba tidak akan menangani kasus itu. Anda harus menggunakan penanganan kesalahan gaya lama. Maaf.".

Setuju, pendapat saya adalah bahwa garis ini harus ditarik saat memeriksa EOF atau serupa, bukan saat membungkus. Tetapi mungkin jika kesalahan memiliki lebih banyak konteks, ini tidak akan menjadi masalah lagi.

Bisakah kesalahan bungkus otomatis try() dengan konteks yang berguna untuk debugging? Misalnya jika xerrors menjadi errors , kesalahan harus memiliki sesuatu yang terlihat seperti jejak tumpukan yang dapat ditambahkan oleh try() , bukan? Jika demikian mungkin itu sudah cukup

Jika tujuannya adalah (baca https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md):

• menghilangkan boilerplate
• perubahan bahasa minimal
• mencakup "skenario paling umum"
• menambahkan sedikit kerumitan pada bahasa

Saya akan mengambil saran memberikan sudut dan mengizinkan migrasi kode "langkah kecil" untuk semua miliaran baris kode di luar sana.

alih-alih yang disarankan:

func printSum(a, b string) error {
        defer fmt.HandleErrorf(&err, "sum %s %s: %v", a,b, err) 
        x := try(strconv.Atoi(a))
        y := try(strconv.Atoi(b))
        fmt.Println("result:", x + y)
        return nil
}

Kita dapat:

func printSum(a, b string) error {
        var err ErrHandler{HandleFunc : twoStringsErr("printSum",a,b)} 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        return nil
}

Apa yang akan kita peroleh?
twoStringsErr dapat digarisbawahi ke printSum, atau penangan umum yang tahu cara menangkap kesalahan (dalam hal ini dengan 2 parameter string) - jadi jika saya memiliki tanda tangan fungsi berulang yang sama yang digunakan di banyak fungsi saya, saya tidak perlu menulis ulang penangan masing-masing waktu
dengan cara yang sama, saya dapat membuat tipe ErrHandler diperpanjang dengan cara:

type ioErrHandler ErrHandler
func (i ErrHandler) Handle() ...{

}

atau

type parseErrHandler ErrHandler
func (p parseErrHandler) Handle() ...{

}

atau

type str2IntErrHandler ErrHandler
func (s str2IntErrHandler) Handle() ...{

}

dan gunakan ini di sekitar kode saya:

func printSum(a, b string) error {
        var pErr str2IntErrHandler 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        return nil
}

Jadi, kebutuhan sebenarnya adalah mengembangkan pemicu ketika err.Error disetel ke tidak nil
Dengan menggunakan metode ini kita juga dapat:

func (s str2IntErrHandler) Handle() bool{
   **return false**
}

Yang akan memberi tahu fungsi panggilan untuk melanjutkan alih-alih kembali

Dan gunakan penangan kesalahan yang berbeda dalam fungsi yang sama:

func printSum(a, b string) error {
        var pErr str2IntErrHandler 
        var oErr overflowError 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        totalAsByte,oErr := sumBytes(x,y)
        sunAsByte,oErr := subtractBytes(x,y)
        return nil
}

dll.

Melewati tujuan lagi

• hilangkan boilerplate - selesai
• perubahan bahasa minimal - selesai
• mencakup "skenario paling umum" - lebih dari yang disarankan IMO
• menambahkan sedikit kerumitan pada bahasa - sone
  Plus - migrasi kode lebih mudah dari

x, err := strconv.Atoi(a)

ke

x, err.Error := strconv.Atoi(a)

dan sebenarnya - keterbacaan yang lebih baik (IMO, lagi)

@guybrand Anda adalah penganut terbaru untuk tema berulang ini (yang saya suka).

Lihat https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

@guybrand Itu sepertinya proposal yang sama sekali berbeda; Saya pikir Anda harus mengajukannya sebagai masalah sendiri sehingga yang ini dapat fokus membahas proposal @griesemer .

@natefinch setuju. Saya pikir ini lebih diarahkan untuk meningkatkan pengalaman saat menulis Go daripada mengoptimalkan untuk membaca. Saya ingin tahu apakah makro atau cuplikan IDE dapat menyelesaikan masalah tanpa ini menjadi fitur bahasa.

@Goodwine

Katakanlah itu praktik yang baik untuk membungkus kesalahan dengan konteks yang berguna, try() akan dianggap sebagai praktik yang buruk karena tidak menambahkan konteks apa pun. Ini berarti bahwa try() adalah fitur yang tidak ingin digunakan oleh siapa pun dan menjadi fitur yang sangat jarang digunakan sehingga mungkin juga tidak ada.

Seperti disebutkan dalam proposal (dan ditunjukkan dengan contoh), try dasarnya tidak mencegah Anda menambahkan konteks. Saya akan mengatakan bahwa cara itu diusulkan, menambahkan konteks ke kesalahan sepenuhnya ortogonal untuk itu. Ini dibahas secara khusus di FAQ proposal.

Saya menyadari bahwa try tidak akan berguna jika dalam satu fungsi jika ada banyak konteks berbeda yang ingin Anda tambahkan ke kesalahan berbeda dari panggilan fungsi. Namun, saya juga percaya bahwa sesuatu dalam nada umum HandleErrorf mencakup area penggunaan yang luas karena hanya menambahkan konteks fungsi ke kesalahan bukanlah hal yang tidak biasa.

Daripada hanya mengatakan "baiklah, jika Anda tidak menyukainya, jangan gunakan dan tutup mulut" (ini adalah bagaimana membaca), saya pikir akan lebih baik untuk mencoba untuk mengatasi apa yang banyak digunakan untuk mempertimbangkan cacat dalam desain.

Jika itu adalah bagaimana membaca saya minta maaf. Maksud saya bukanlah bahwa Anda harus berpura-pura bahwa itu tidak ada jika Anda tidak menyukainya. Jelas bahwa ada kasus di mana try tidak akan berguna dan Anda tidak boleh menggunakannya dalam kasus seperti itu, yang untuk proposal ini saya percaya memberikan keseimbangan yang baik antara KISS dan utilitas umum. Saya tidak berpikir bahwa saya tidak jelas pada saat itu.

Terima kasih semuanya atas umpan balik yang produktif sejauh ini; ini sangat informatif.
Inilah upaya saya pada ringkasan awal, untuk mendapatkan perasaan yang lebih baik untuk umpan balik. Permintaan maaf sebelumnya untuk siapa pun yang saya lewatkan atau salah mengartikan; Saya harap saya mendapatkan inti keseluruhannya dengan benar.

0) Sisi positifnya, @rasky , @adg , @eandre , @dpinela , dan lainnya secara eksplisit menyatakan kebahagiaan atas penyederhanaan kode yang diberikan try .

1) Perhatian yang paling penting tampaknya adalah bahwa try tidak mendorong gaya penanganan kesalahan yang baik tetapi malah mempromosikan "keluar cepat". ( @agnivade , @peterbourgon , @politician , @a8m , @eandre , @prologic , @kungfusheep , @cpuguy , dan lainnya telah menyuarakan keprihatinan mereka tentang ini.)

2) Banyak orang tidak menyukai ide built-in, atau sintaks fungsi yang menyertainya karena menyembunyikan return . Akan lebih baik menggunakan kata kunci. ( @sheerun , @Redundancy , @dolmen , @komuw , @RobertGrantEllis , @elagergren-spideroak). try juga dapat dengan mudah diabaikan (@peterbourgon), terutama karena dapat muncul dalam ekspresi yang mungkin bersarang secara sewenang-wenang. @natefinch khawatir bahwa try membuatnya "terlalu mudah untuk membuang terlalu banyak dalam satu baris", sesuatu yang biasanya kami coba hindari di Go. Juga, dukungan IDE untuk menekankan try mungkin tidak cukup (@dominikh); try perlu "berdiri sendiri".

3) Bagi sebagian orang, status quo dari pernyataan if eksplisit tidak menjadi masalah, mereka senang dengan itu ( @bitfield , @marwan-at-work, @natefinch). Lebih baik hanya memiliki satu cara untuk melakukan sesuatu (@gbbr); dan pernyataan if eksplisit lebih baik daripada pernyataan return implisit ( @DavexPro , @hmage , @prologic , @natefinch).
Sejalan dengan itu, @mattn prihatin tentang "pengikatan implisit" dari hasil kesalahan ke try - koneksi tidak terlihat secara eksplisit dalam kode.

4) Menggunakan try akan mempersulit proses debug kode; misalnya, mungkin perlu untuk menulis ulang ekspresi try kembali ke pernyataan if hanya agar pernyataan debug dapat dimasukkan ( @deanveloper , @typeless , @networkimprov , others).

5) Ada beberapa kekhawatiran tentang penggunaan pengembalian bernama ( @buchanae , @adg).

Beberapa orang telah memberikan saran untuk memperbaiki atau memodifikasi proposal:

6) Beberapa telah mengambil ide penangan kesalahan opsional (@beoran) atau string format yang disediakan untuk try ( @unexge , @a8m , @eandre , @gotwarlost) untuk mendorong penanganan kesalahan yang baik.

7) @pierrec menyarankan bahwa gofmt dapat memformat ekspresi try dengan tepat agar lebih terlihat.
Alternatifnya, seseorang dapat membuat kode yang ada menjadi lebih ringkas dengan mengizinkan gofmt memformat pernyataan if yang memeriksa kesalahan pada satu baris (@zeebo).

8) @marwan-at-work berpendapat bahwa try hanya menggeser penanganan kesalahan dari pernyataan if try ke ekspresi try. Sebaliknya, jika kita ingin benar-benar menyelesaikan masalah, Go harus "memiliki" penanganan kesalahan dengan membuatnya benar-benar implisit. Tujuannya adalah untuk membuat penanganan kesalahan (yang tepat) lebih sederhana dan pengembang lebih produktif (@cpuguy).

9) Akhirnya, beberapa orang tidak suka nama try ( @beoran , @HiImJC , @dolmen) atau lebih suka simbol seperti ? ( @twisted1919 , @leaxoy , others) .

Beberapa komentar tentang umpan balik ini (diberi nomor yang sesuai):

0) Terima kasih atas umpan balik positifnya! :-)

1) Akan lebih baik untuk mempelajari lebih lanjut tentang masalah ini. Gaya pengkodean saat ini menggunakan pernyataan if untuk menguji kesalahan adalah sejelas mungkin. Sangat mudah untuk menambahkan informasi tambahan ke kesalahan, secara individual (untuk setiap if ). Seringkali masuk akal untuk menangani semua kesalahan yang terdeteksi dalam suatu fungsi dengan cara yang seragam, yang dapat dilakukan dengan defer - ini sudah dimungkinkan sekarang. Fakta bahwa kita sudah memiliki semua alat untuk penanganan kesalahan yang baik dalam bahasa, dan masalah konstruksi pengendali yang tidak ortogonal dengan defer , yang membuat kita meninggalkan mekanisme baru hanya untuk menambah kesalahan .

2) Tentu saja ada kemungkinan untuk menggunakan kata kunci atau sintaks khusus alih-alih built-in. Kata kunci baru tidak akan kompatibel ke belakang. Operator baru mungkin, tetapi tampaknya semakin tidak terlihat. Proposal rinci membahas berbagai pro dan kontra panjang lebar. Tapi mungkin kita salah menilai ini.

3) Alasan proposal ini adalah bahwa penanganan kesalahan (khususnya kode boilerplate terkait) disebutkan sebagai masalah signifikan di Go (di samping kurangnya obat generik) oleh komunitas Go. Proposal ini secara langsung membahas masalah boilerplate. Itu tidak lebih dari menyelesaikan kasus paling dasar karena kasus yang lebih kompleks lebih baik ditangani dengan apa yang sudah kita miliki. Jadi, sementara sejumlah besar orang senang dengan status quo, ada (mungkin) kontingen orang yang sama besarnya yang akan menyukai pendekatan yang lebih ramping seperti try , mengetahui dengan baik bahwa ini "adil" gula sintaksis.

4) Titik debugging adalah perhatian yang valid. Jika ada kebutuhan untuk menambahkan kode antara mendeteksi kesalahan dan return , harus menulis ulang ekspresi try menjadi pernyataan if dapat mengganggu.

5) Nilai pengembalian yang dinamai: Dokumen terperinci membahas hal ini secara panjang lebar. Jika ini adalah perhatian utama tentang proposal ini, maka kami berada di tempat yang bagus, saya pikir.

6) Argumen handler opsional ke try : Dokumen rinci membahas ini juga. Lihat bagian tentang iterasi Desain.

7) Menggunakan gofmt untuk memformat ekspresi try sedemikian rupa sehingga lebih terlihat tentu akan menjadi pilihan. Tapi itu akan menghilangkan beberapa manfaat dari try saat digunakan dalam sebuah ekspresi.

8) Kami telah mempertimbangkan untuk melihat masalah dari sudut pandang penanganan kesalahan ( handle ) daripada dari sudut pandang pengujian kesalahan ( try ). Secara khusus, kami secara singkat mempertimbangkan hanya memperkenalkan gagasan penangan kesalahan (mirip dengan draf desain asli yang dipresentasikan di Gophercon tahun lalu). Pemikirannya adalah jika (dan hanya jika) penangan dideklarasikan, dalam penugasan multi-nilai di mana nilai terakhir bertipe error , nilai itu dapat dibiarkan begitu saja dalam penugasan. Kompiler akan secara implisit memeriksa apakah itu bukan nihil, dan jika demikian bercabang ke pawang. Itu akan membuat penanganan kesalahan eksplisit hilang sepenuhnya dan mendorong semua orang untuk menulis penangan sebagai gantinya. Ini tampaknya merupakan pendekatan yang ekstrem karena akan sepenuhnya implisit - fakta bahwa cek terjadi tidak akan terlihat.

9) Bolehkah saya menyarankan agar kita tidak melepaskan nama sepeda pada saat ini. Setelah semua masalah lain diselesaikan adalah waktu yang lebih baik untuk menyempurnakan nama.

Ini bukan untuk mengatakan bahwa kekhawatiran itu tidak valid - jawaban di atas hanya menyatakan pemikiran kita saat ini. Ke depan, akan lebih baik untuk mengomentari masalah baru (atau bukti baru yang mendukung kekhawatiran ini) - hanya menyatakan kembali apa yang telah dikatakan tidak memberi kami informasi lebih lanjut.

Dan akhirnya, tampaknya tidak semua orang yang mengomentari masalah ini telah membaca dokumen terperinci. Harap lakukan sebelum berkomentar untuk menghindari mengulangi apa yang telah dikatakan. Terima kasih.

Ini bukan komentar atas proposal, tapi laporan salah ketik. Itu tidak diperbaiki sejak proposal lengkap diterbitkan, jadi saya pikir saya akan menyebutkannya:

func try(t1 T1, t1 T2, … tn Tn, te error) (T1, T2, … Tn)

seharusnya:

func try(t1 T1, t2 T2, … tn Tn, te error) (T1, T2, … Tn)

Apakah layak untuk menganalisis kode Go yang tersedia secara terbuka untuk pernyataan pemeriksaan kesalahan untuk mencoba dan mencari tahu apakah sebagian besar pemeriksaan kesalahan benar-benar berulang atau jika dalam banyak kasus, beberapa pemeriksaan dalam fungsi yang sama menambahkan informasi kontekstual yang berbeda? Proposal akan sangat masuk akal untuk kasus pertama tetapi tidak akan membantu yang terakhir. Dalam kasus terakhir, orang akan terus menggunakan if err != nil atau menyerah untuk menambahkan konteks tambahan, menggunakan try() dan resor untuk menambahkan konteks kesalahan umum per fungsi yang IMO akan berbahaya. Dengan fitur nilai kesalahan yang akan datang, saya pikir kami berharap orang-orang membungkus kesalahan dengan lebih banyak info lebih sering. Mungkin saya salah memahami proposal tetapi AFAIU, ini membantu mengurangi boilerplate hanya ketika semua kesalahan dari satu fungsi harus dibungkus dengan tepat satu cara dan tidak membantu jika suatu fungsi menangani lima kesalahan yang mungkin perlu dibungkus secara berbeda. Tidak yakin seberapa umum kasus seperti itu di alam liar (cukup umum di sebagian besar proyek saya) tetapi saya khawatir try() mungkin mendorong orang untuk menggunakan pembungkus umum per fungsi bahkan ketika masuk akal untuk membungkus kesalahan yang berbeda berbeda.

Hanya komentar singkat yang didukung dengan data kumpulan sampel kecil:

Kami mengusulkan fungsi bawaan baru yang disebut try, yang dirancang khusus untuk menghilangkan pernyataan boilerplate if yang biasanya terkait dengan penanganan kesalahan di Go

Jika ini adalah masalah inti yang diselesaikan oleh proposal ini, saya menemukan bahwa "boilerplate" ini hanya menyumbang ~1,4% dari kode saya di lusinan proyek sumber terbuka yang tersedia untuk umum dengan total ~60rb SLOC.

Penasaran apakah ada orang lain yang memiliki statistik serupa?

Pada basis kode yang jauh lebih besar seperti Go itu sendiri dengan total sekitar ~1,6 juta SLOC, ini berjumlah sekitar ~0,5% dari basis kode yang memiliki baris seperti if err != nil .

Apakah ini benar-benar masalah yang paling berdampak untuk dipecahkan dengan Go 2?

Terima kasih banyak @griesemer telah meluangkan waktu untuk membahas ide-ide semua orang dan secara eksplisit memberikan pemikiran. Saya pikir itu sangat membantu dengan persepsi bahwa masyarakat didengar dalam prosesnya.

1. @pierrec menyarankan agar gofmt dapat memformat ekspresi try yang sesuai untuk membuatnya lebih terlihat.
   Sebagai alternatif, seseorang dapat membuat kode yang ada menjadi lebih ringkas dengan mengizinkan gofmt memformat pernyataan if yang memeriksa kesalahan pada satu baris (@zeebo).

1. Menggunakan gofmt untuk memformat ekspresi try sedemikian rupa sehingga lebih terlihat tentu akan menjadi pilihan. Tapi itu akan menghilangkan beberapa manfaat dari try saat digunakan dalam ekspresi.

Ini adalah pemikiran berharga tentang mengharuskan gofmt untuk memformat try , tapi saya tertarik jika ada pemikiran khusus tentang gofmt mengizinkan pemeriksaan pernyataan if kesalahan menjadi satu baris. Proposal disatukan dengan format try , tapi saya pikir itu adalah hal yang sepenuhnya ortogonal. Terima kasih.

@griesemer terima kasih atas kerja luar biasa melalui semua komentar dan menjawab sebagian besar jika tidak semua umpan balik

Satu hal yang tidak dibahas dalam umpan balik Anda adalah gagasan untuk menggunakan bagian perkakas/pemeriksaan bahasa Go untuk meningkatkan pengalaman penanganan kesalahan, daripada memperbarui sintaks Go.

Misalnya, dengan pendaratan LSP baru ( gopls ), sepertinya ini adalah tempat yang sempurna untuk menganalisis tanda tangan suatu fungsi dan menangani boilerplate penanganan kesalahan untuk pengembang, dengan pembungkusan dan pemeriksaan yang tepat juga.

@griesemer Saya yakin ini tidak dipikirkan dengan matang, tetapi saya mencoba mengubah saran Anda lebih dekat ke sesuatu yang saya rasa nyaman di sini: https://www.reddit.com/r/golang/comments/bwvyhe /proposal_a_builtin_go_error_check_function_try/eq22bqa?utm_source=share&utm_medium=web2x

@zeebo Akan mudah untuk membuat format $ gofmt if err != nil { return ...., err } dalam satu baris. Agaknya itu hanya untuk jenis pola if khusus ini, tidak semua pernyataan if "pendek"?

Sejalan dengan itu, ada kekhawatiran tentang try tidak terlihat karena berada di jalur yang sama dengan logika bisnis. Kami memiliki semua opsi ini:

Gaya saat ini:

a, b, c, ... err := BusinessLogic(...)
if err != nil {
   return ..., err
}

Satu baris if :

a, b, c, ... err := BusinessLogic(...)
if err != nil { return ..., err }

try pada baris terpisah (!):

a, b, c, ... err := BusinessLogic(...)
try(err)

try seperti yang diusulkan:

a, b, c := try(BusinessLogic(...))

Baris pertama dan terakhir tampak paling jelas (bagi saya), terutama setelah digunakan untuk mengenali try apa adanya. Dengan baris terakhir, kesalahan secara eksplisit diperiksa, tetapi karena itu (biasanya) bukan tindakan utama, itu sedikit lebih banyak di latar belakang.

@marwan-at-work Saya tidak yakin apa yang Anda usulkan bahwa alat itu berfungsi untuk Anda. Apakah Anda menyarankan agar mereka menyembunyikan penanganan kesalahan?

@dpinela

@guybrand Itu sepertinya proposal yang sama sekali berbeda; Saya pikir Anda harus mengajukannya sebagai masalah sendiri sehingga yang ini dapat fokus membahas proposal @griesemer .

IMO proposal saya hanya berbeda dalam sintaks, artinya:

• Tujuan serupa dalam konten dan prioritas.
• Gagasan menangkap setiap err dalam barisnya sendiri dan karenanya (jika tidak nihil) keluar dari fungsi saat melewati fungsi handler serupa (pseudo asm - ini adalah "jnz" dan "panggilan").
• Ini bahkan berarti jumlah baris dalam badan fungsi (tanpa penangguhan) dan aliran akan terlihat persis sama (dan karenanya AST mungkin akan menjadi sama juga)

jadi perbedaan utamanya adalah apakah kita membungkus panggilan fungsi asli dengan try(func()) yang akan selalu menganalisis var terakhir ke jnz panggilan atau menggunakan nilai pengembalian aktual untuk melakukannya.

Saya tahu ini terlihat berbeda, tetapi sebenarnya sangat mirip dalam konsep.
Di sisi lain - jika Anda mencoba yang biasa .... tangkap dalam banyak bahasa mirip-c - itu akan menjadi implementasi yang sangat berbeda, keterbacaan yang berbeda, dll.

Namun saya benar-benar berpikir untuk menulis proposal, terima kasih atas idenya.

@griesemer

Saya tidak yakin apa yang Anda usulkan bahwa alat itu berfungsi untuk Anda. Apakah Anda menyarankan agar mereka menyembunyikan penanganan kesalahan?

Justru sebaliknya: Saya menyarankan bahwa gopls secara opsional dapat menulis boilerplate penanganan kesalahan untuk Anda.

Seperti yang Anda sebutkan dalam komentar terakhir Anda:

Alasan proposal ini adalah bahwa penanganan kesalahan (khususnya kode boilerplate terkait) disebutkan sebagai masalah signifikan di Go (di samping kurangnya obat generik) oleh komunitas Go

Jadi inti masalahnya adalah programmer akhirnya menulis banyak kode boilerplate. Jadi masalahnya adalah tentang menulis, bukan membaca. Oleh karena itu, saran saya adalah: biarkan komputer (tooling/gopls) melakukan penulisan untuk programmer dengan menganalisis tanda tangan fungsi dan menempatkan klausa penanganan kesalahan yang tepat.

Sebagai contoh:

// user begins to write this function: 
func openFile(path string) ([]byte, error) {
  file, err := os.Open(path)
  defer file.Close()
  bts, err := ioutil.ReadAll(file)
  return bts, nil
}

Kemudian pengguna mengaktifkan alat, mungkin hanya dengan menyimpan file (mirip dengan cara kerja gofmt/goimports) dan gopls akan melihat fungsi ini, menganalisis tanda tangan kembalinya, dan menambahkan kode menjadi ini:

// user has triggered the tool (by saving the file, or code action)
func openFile(path string) ([]byte, error) {
  file, err := os.Open(path)
  if err != nil {
    return nil, fmt.Errorf("openFile: %w", err)
  }
  defer file.Close()
  bts, err := ioutil.ReadAll(file)
  if err != nil {
    return nil, fmt.Errorf("openFile: %w", err)
  }
  return bts, nil
}

Dengan cara ini, kami mendapatkan yang terbaik dari kedua dunia: kami mendapatkan keterbacaan/eksplisititas sistem penanganan kesalahan saat ini, dan programmer tidak menulis boilerplate penanganan kesalahan apa pun . Lebih baik lagi, pengguna dapat melanjutkan dan memodifikasi blok penanganan kesalahan nanti untuk melakukan perilaku yang berbeda: gopls dapat memahami bahwa blok tersebut ada, dan tidak akan mengubahnya.

Bagaimana alat tahu bahwa saya bermaksud menangani err nanti dalam fungsi alih-alih kembali lebih awal? Meski jarang, tapi kode tetap saya tulis.

Saya minta maaf jika ini telah diangkat sebelumnya, tetapi saya tidak dapat menemukan penyebutan itu.

try(DoSomething()) cocok untuk saya, dan masuk akal: kodenya mencoba melakukan sesuatu. try(err) , OTOH, terasa sedikit aneh, secara semantik: bagaimana cara mencoba kesalahan? Dalam pikiran saya, seseorang dapat _test_ atau _check_ kesalahan, tetapi _mencoba_ tampaknya tidak benar.

Saya menyadari bahwa mengizinkan try(err) penting untuk alasan konsistensi: Saya kira akan aneh jika try(DoSomething()) berhasil, tetapi err := DoSomething(); try(err) tidak. Namun, sepertinya try(err) terlihat sedikit canggung di halaman. Saya tidak dapat memikirkan fungsi bawaan lainnya yang dapat dibuat terlihat aneh ini dengan mudah.

Saya tidak punya saran konkret tentang masalah ini, tetapi saya tetap ingin melakukan pengamatan ini.

@griesemer Terima kasih. Memang, proposal itu hanya untuk return , tetapi saya menduga membiarkan satu pernyataan menjadi satu baris akan baik. Misalnya dalam pengujian, seseorang dapat, tanpa perubahan pada pustaka pengujian, memiliki

if err != nil { t.Fatal(err) }

Baris pertama dan terakhir tampak paling jelas (bagi saya), terutama setelah digunakan untuk mengenali try apa adanya. Dengan baris terakhir, kesalahan secara eksplisit diperiksa, tetapi karena itu (biasanya) bukan tindakan utama, itu sedikit lebih banyak di latar belakang.

Dengan baris terakhir, sebagian biaya disembunyikan. Jika Anda ingin membuat anotasi kesalahan, yang saya yakini secara vokal dikatakan oleh komunitas sebagai praktik terbaik yang diinginkan dan harus didorong, seseorang harus mengubah tanda tangan fungsi untuk memberi nama argumen dan berharap satu defer diterapkan ke setiap keluar di badan fungsi, jika tidak try tidak memiliki nilai; bahkan mungkin negatif karena kemudahannya.

Saya tidak punya lagi untuk menambahkan yang saya yakin belum dikatakan.

Saya tidak melihat bagaimana menjawab pertanyaan ini dari dokumen desain. Apa yang dilakukan kode ini:

func foo() (err error) {
    src := try(getReader())
    if src != nil {
        n, err := src.Read(nil)
        if err == io.EOF {
            return nil
        }
        try(err)
        println(n)
    }
    return nil
}

Pemahaman saya adalah bahwa itu akan berubah menjadi

func foo() (err error) {
    tsrc, te := getReader()
    if err != nil {
        err = te
        return
    }
    src := tsrc

    if src != nil {
        n, err := src.Read(nil)
        if err == io.EOF {
            return nil
        }

        terr := err
        if terr != nil {
            err = terr
            return
        }

        println(n)
    }
    return nil
}

yang gagal dikompilasi karena err dibayangi selama pengembalian telanjang. Apakah ini tidak akan dikompilasi? Jika demikian, itu adalah kegagalan yang sangat halus, dan sepertinya tidak terlalu mungkin terjadi. Jika tidak, maka lebih banyak yang terjadi daripada gula.

@marwan-di-kerja

Seperti yang Anda sebutkan dalam komentar terakhir Anda:

Alasan proposal ini adalah bahwa penanganan kesalahan (khususnya kode boilerplate terkait) disebutkan sebagai masalah signifikan di Go (di samping kurangnya obat generik) oleh komunitas Go

Jadi inti masalahnya adalah programmer akhirnya menulis banyak kode boilerplate. Jadi masalahnya adalah tentang menulis, bukan membaca.

Saya pikir itu sebenarnya sebaliknya - bagi saya gangguan terbesar dengan boilerplate penanganan kesalahan saat ini tidak begitu banyak harus mengetiknya, melainkan bagaimana menyebarkan jalur bahagia fungsi secara vertikal di layar, membuatnya lebih sulit untuk dipahami di sekilas. Efeknya sangat terasa dalam kode I/O-berat, di mana biasanya ada blok boilerplate di antara setiap dua operasi. Bahkan versi sederhana dari CopyFile membutuhkan ~20 baris meskipun sebenarnya hanya melakukan lima langkah: open source, defer close source, open destination, copy source -> destination, close destination.

Masalah lain dengan sintaks saat ini, adalah bahwa, seperti yang saya sebutkan sebelumnya, jika Anda memiliki rantai operasi yang masing-masing dapat mengembalikan kesalahan, sintaks saat ini memaksa Anda untuk memberi nama pada semua hasil antara, bahkan jika Anda lebih suka meninggalkan beberapa anonim. Ketika ini terjadi, itu juga mengganggu keterbacaan karena Anda harus menghabiskan siklus otak untuk menguraikan nama-nama itu, meskipun itu tidak terlalu informatif.

Saya suka try pada baris terpisah.
Dan saya berharap dapat menentukan fungsi handler secara mandiri.

func try(error, optional func(error)error)

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    try(err)

    handle := func(err error) error {
        tx.Rollback()
        return err
    }

    var res int64
    _, err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    try(err, handle)

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    try(err, handle)

    return tx.Commit()
}

@zeebo : Contoh yang saya berikan adalah terjemahan 1:1. Yang pertama (tradisional if ) tidak menangani kesalahan, dan yang lain tidak. Jika yang pertama menangani kesalahan, dan jika ini adalah satu-satunya tempat kesalahan diperiksa dalam suatu fungsi, contoh pertama (menggunakan if ) mungkin merupakan pilihan yang tepat untuk menulis kode. Jika ada beberapa pemeriksaan kesalahan, yang semuanya menggunakan penanganan kesalahan (pembungkusan) yang sama, katakan karena semuanya menambahkan informasi tentang fungsi saat ini, seseorang dapat menggunakan pernyataan defer untuk menangani semua kesalahan di satu tempat. Secara opsional, seseorang dapat menulis ulang if 's menjadi try 's (atau biarkan saja). Jika ada beberapa kesalahan yang harus diperiksa, dan semuanya menangani kesalahan secara berbeda (yang mungkin merupakan tanda bahwa perhatian fungsi terlalu luas dan mungkin perlu dipisahkan), menggunakan if 's adalah jalan untuk pergi. Ya, ada lebih dari satu cara untuk melakukan hal yang sama, dan pilihan yang tepat tergantung pada kode serta selera pribadi. Meskipun kami berusaha keras di Go untuk "satu cara untuk melakukan satu hal", ini tentu saja tidak demikian, terutama untuk konstruksi umum. Misalnya, ketika urutan if - else - if menjadi terlalu panjang, terkadang switch mungkin lebih tepat. Terkadang deklarasi variabel var x int mengekspresikan maksud lebih baik daripada x := 0 , dan seterusnya (meskipun tidak semua orang senang dengan ini).

Mengenai pertanyaan Anda tentang "menulis ulang": Tidak, tidak akan ada kesalahan kompilasi. Perhatikan bahwa penulisan ulang terjadi secara internal (dan mungkin lebih efisien daripada yang disarankan oleh pola kode), dan kompiler tidak perlu mengeluh tentang pengembalian yang dibayangi. Dalam contoh Anda, Anda mendeklarasikan variabel err lokal dalam lingkup bersarang. try masih akan memiliki akses langsung ke variabel hasil err , tentu saja. Penulisan ulang mungkin terlihat lebih seperti ini di balik sampul.

[diedit] PS: Jawaban yang lebih baik adalah: try bukan pengembalian telanjang (meskipun penulisan ulang terlihat seperti itu). Bagaimanapun, seseorang secara eksplisit memberikan try argumen yang berisi (atau merupakan) kesalahan yang dikembalikan jika tidak nil . Kesalahan bayangan untuk pengembalian telanjang adalah kesalahan pada sumbernya (bukan terjemahan yang mendasari sumbernya. Kompilator tidak memerlukan kesalahan tersebut.

Jika tipe pengembalian akhir fungsi menyeluruh bukan dari kesalahan tipe, dapatkah kita panik?

Ini akan membuat builtin lebih fleksibel (seperti memuaskan kekhawatiran saya di #32219)

@pjebs Ini telah dipertimbangkan dan diputuskan. Harap baca dokumen desain terperinci (yang secara eksplisit merujuk pada masalah Anda tentang hal ini).

Saya juga ingin menunjukkan bahwa try() diperlakukan sebagai ekspresi meskipun berfungsi sebagai pernyataan pengembalian. Ya, saya tahu try adalah makro bawaan tetapi sebagian besar pengguna akan menggunakan ini seperti pemrograman fungsional, saya kira.

func doSomething() (error, error, error, error, error) {
   ...
}

try(try(try(try(try(doSomething)))))

Desainnya mengatakan Anda menjelajahi menggunakan panic alih-alih kembali dengan kesalahan.

Saya menyoroti perbedaan halus:

Lakukan persis seperti yang dinyatakan proposal Anda saat ini, kecuali hapus batasan bahwa fungsi menyeluruh harus memiliki tipe pengembalian akhir dari tipe error .

Jika tidak memiliki tipe pengembalian akhir error => panic
Jika menggunakan coba untuk deklarasi variabel tingkat paket => panik (menghapus kebutuhan untuk konvensi MustXXX( ) )

Untuk pengujian unit, perubahan bahasa sederhana.

@mattn , saya sangat ragu ada banyak orang yang akan menulis kode seperti itu.

@pjebs , semantik itu - panik jika tidak ada hasil kesalahan dalam fungsi saat ini - persis seperti yang dibahas oleh dokumen desain di https://github.com/golang/proposal/blob/master/design/32437-try-builtin. md#diskusi.

Selanjutnya, dalam upaya untuk membuat try berguna tidak hanya di dalam fungsi dengan hasil kesalahan, semantik try bergantung pada konteksnya: Jika try digunakan pada tingkat paket, atau jika dipanggil di dalam fungsi tanpa hasil kesalahan, try akan panik saat menemui kesalahan. (Selain itu, karena properti itu, built-in disebut must daripada try dalam proposal itu.) Memiliki try (atau must) berperilaku dalam cara yang peka konteks ini tampak alami dan juga cukup berguna: Ini akan memungkinkan penghapusan banyak fungsi penolong yang harus ditentukan pengguna yang saat ini digunakan dalam ekspresi inisialisasi variabel tingkat paket. Itu juga akan membuka kemungkinan menggunakan try in unit test melalui paket pengujian.

Namun, sensitivitas konteks dari try dianggap penuh: Misalnya, perilaku fungsi yang berisi panggilan try dapat berubah secara diam-diam (dari mungkin panik menjadi tidak panik, dan sebaliknya) jika hasil kesalahan ditambahkan atau dihapus dari tanda tangan. Tampaknya ini properti yang terlalu berbahaya. Solusi yang jelas adalah dengan membagi fungsionalitas try menjadi dua fungsi terpisah, must dan try (sangat mirip dengan apa yang disarankan oleh masalah #31442). Tapi itu akan membutuhkan dua fungsi built-in baru, dengan hanya mencoba terhubung langsung ke kebutuhan mendesak untuk dukungan penanganan kesalahan yang lebih baik.

@pjebs Itulah _persis_ yang kami pertimbangkan dalam proposal sebelumnya (lihat dokumen terperinci, bagian tentang iterasi Desain, paragraf ke-4):

Selanjutnya, dalam upaya untuk membuat try berguna tidak hanya di dalam fungsi dengan hasil kesalahan, semantik try bergantung pada konteksnya: Jika try digunakan pada tingkat paket, atau jika dipanggil di dalam fungsi tanpa hasil kesalahan, try akan panik saat menemui kesalahan. (Sebagai tambahan, karena properti itu, built-in dipanggil harus daripada mencoba dalam proposal itu.)

Konsensus (Go Team internal) adalah bahwa akan membingungkan jika try bergantung pada konteks dan bertindak secara berbeda. Misalnya, menambahkan hasil kesalahan ke suatu fungsi (atau menghapusnya) dapat secara diam-diam mengubah perilaku fungsi dari panik menjadi tidak panik (atau sebaliknya).

@griesemer Terima kasih atas klarifikasi tentang penulisan ulang. Saya senang itu akan dikompilasi.

Saya mengerti bahwa contohnya adalah terjemahan yang tidak menjelaskan kesalahannya. Saya mencoba berargumen bahwa try mempersulit untuk melakukan anotasi kesalahan yang baik dalam situasi umum, dan anotasi kesalahan itu sangat penting bagi komunitas. Sebagian besar komentar sejauh ini telah mengeksplorasi cara untuk menambahkan dukungan anotasi yang lebih baik ke try .

Tentang harus menangani kesalahan secara berbeda, saya tidak setuju bahwa itu adalah tanda bahwa perhatian fungsi terlalu luas. Saya telah menerjemahkan beberapa contoh kode nyata yang diklaim dari komentar dan menempatkannya di dropdown di bagian bawah komentar asli saya, dan contoh di https://github.com/golang/go/issues/32437#issuecomment - 499007288 Saya pikir menunjukkan kasus umum dengan baik:

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil { return nil, errors.WithMessage(err, "load config dir") }

    b := bytes.NewBuffer(nil)
    err = templates.ExecuteTemplate(b, "main", c)
    if err != nil { return nil, errors.WithMessage(err, "execute main template") }

    buf, err := format.Source(b.Bytes())
    if err != nil { return nil, errors.WithMessage(err, "format main template") }

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    err = ioutil.WriteFile(target, buf, 0644)
    if err != nil { return nil, errors.WithMessagef(err, "write file %s", target) }
    // ...
}

Tujuan fungsi itu adalah untuk mengeksekusi template pada beberapa data ke dalam file. Saya tidak percaya itu perlu dipecah, dan akan sangat disayangkan jika semua kesalahan itu baru saja mendapatkan garis yang mereka buat dari penangguhan. Itu mungkin baik-baik saja untuk pengembang, tetapi itu kurang berguna bagi pengguna.

Saya pikir itu juga sedikit sinyal betapa halusnya bug defer wrap(&err, "message: %v", err) dan bagaimana mereka tersandung bahkan oleh programmer Go yang berpengalaman.

Untuk meringkas argumen saya : Saya pikir anotasi kesalahan lebih penting daripada pemeriksaan kesalahan berbasis ekspresi, dan kita bisa mendapatkan sedikit pengurangan kebisingan dengan mengizinkan pemeriksaan kesalahan berbasis pernyataan menjadi satu baris, bukan tiga. Terima kasih.

@griesemer maaf saya membaca bagian berbeda yang membahas kepanikan dan tidak melihat diskusi tentang bahaya.

@zeebo Terima kasih untuk contoh ini. Sepertinya menggunakan pernyataan if adalah pilihan yang tepat dalam kasus ini. Tapi intinya, memformat if menjadi satu baris dapat sedikit menyederhanakan ini.

Saya ingin sekali lagi mengemukakan gagasan tentang handler sebagai argumen kedua try , tetapi dengan tambahan bahwa argumen handler menjadi _required_, tetapi nihil-mampu. Ini menjadikan penanganan kesalahan sebagai default, bukan pengecualian. Dalam kasus di mana Anda benar-benar ingin meneruskan kesalahan tanpa perubahan, cukup berikan nilai nil ke pawang dan try akan berperilaku seperti di proposal asli, tetapi argumen nil akan bertindak sebagai isyarat visual bahwa kesalahan tidak ditangani. Akan lebih mudah ditangkap selama peninjauan kode.

file := try(os.Open("my_file.txt"), nil)

Apa yang harus terjadi jika pawang disediakan tetapi nihil? Haruskah mencoba panik atau memperlakukannya sebagai penangan kesalahan yang tidak ada?

Seperti disebutkan di atas, try akan berperilaku sesuai dengan proposal asli. Tidak akan ada yang namanya penangan kesalahan yang tidak ada, hanya yang nihil.

Bagaimana jika pawang dipanggil dengan kesalahan non-nil dan kemudian mengembalikan hasil nihil? Apakah ini berarti kesalahannya "dibatalkan"? Atau haruskah fungsi terlampir kembali dengan kesalahan nihil?

Saya percaya bahwa fungsi terlampir akan kembali dengan kesalahan nihil. Akan sangat membingungkan jika try terkadang dapat melanjutkan eksekusi bahkan setelah menerima nilai kesalahan non-nihil. Ini akan memungkinkan penangan untuk "mengurus" kesalahan dalam beberapa keadaan. Perilaku ini dapat berguna dalam fungsi gaya "dapatkan atau buat", misalnya.

func getOrCreateObject(obj *object) error {
    defaultObjectHandler := func(err error) error {
        if err == ObjectDoesNotExistErr {
            *obj = object{}
            return nil
        }
        return fmt.Errorf("getting or creating object: %v", err)
    }

    *obj = try(db.getObject(), defaultObjectHandler)
}

Juga tidak jelas apakah mengizinkan penangan kesalahan opsional akan membuat pemrogram mengabaikan penanganan kesalahan yang tepat sama sekali. Juga akan mudah untuk melakukan penanganan kesalahan yang tepat di mana-mana tetapi melewatkan satu kejadian percobaan. Dan seterusnya.

Saya percaya bahwa kedua masalah ini diringankan dengan menjadikan pawang sebagai argumen yang diperlukan dan tidak ada habisnya. Ini membutuhkan pemrogram untuk membuat keputusan yang sadar dan eksplisit bahwa mereka tidak akan menangani kesalahan mereka.

Sebagai bonus, saya pikir membutuhkan penangan kesalahan juga membuat try s sangat bersarang karena kurang singkat. Beberapa orang mungkin melihat ini sebagai kerugian, tapi saya pikir ini adalah keuntungan.

@velovix Saya suka idenya, tetapi mengapa penangan kesalahan harus diperlukan? Tidak bisakah nil secara default? Mengapa kita membutuhkan "petunjuk visual"?

@griesemer Bagaimana jika ide @velovix diadopsi tetapi dengan builtin berisi fungsi yang telah ditentukan sebelumnya yang mengubah err menjadi panik DAN Kami menghapus persyaratan bahwa fungsi over-arching memiliki nilai pengembalian kesalahan?

Idenya adalah, jika fungsi menyeluruh tidak mengembalikan kesalahan, menggunakan try tanpa penangan kesalahan adalah kesalahan waktu kompilasi.

Penangan kesalahan juga dapat digunakan untuk membungkus kesalahan yang akan segera dikembalikan menggunakan berbagai pustaka dll di lokasi kesalahan, alih-alih defer di bagian atas yang memodifikasi kesalahan yang dikembalikan bernama.

@pjebs

mengapa penangan kesalahan harus diperlukan? Tidak bisakah itu menjadi nihil secara default? Mengapa kita membutuhkan "petunjuk visual"?

Ini untuk mengatasi kekhawatiran bahwa

1. Proposal try seperti sekarang dapat membuat orang enggan memberikan konteks pada kesalahan mereka karena melakukannya tidak begitu mudah.

Memiliki penangan di tempat pertama membuat penyediaan konteks lebih mudah, dan menjadikan penangan sebagai argumen yang diperlukan mengirim pesan: Kasus umum yang direkomendasikan adalah menangani atau mengontekstualisasikan kesalahan dalam beberapa cara, tidak hanya meneruskannya ke tumpukan. Ini sejalan dengan rekomendasi umum dari komunitas Go.

1. Kekhawatiran dari dokumen proposal asli. Saya mengutipnya di komentar pertama saya:

Juga tidak jelas apakah mengizinkan penangan kesalahan opsional akan membuat pemrogram mengabaikan penanganan kesalahan yang tepat sama sekali. Juga akan mudah untuk melakukan penanganan kesalahan yang tepat di mana-mana tetapi melewatkan satu kejadian percobaan. Dan seterusnya.

Harus melewati nil eksplisit membuat lebih sulit untuk lupa menangani kesalahan dengan benar. Anda harus secara eksplisit memutuskan untuk tidak menangani kesalahan alih-alih melakukannya secara implisit dengan meninggalkan argumen.

Memikirkan lebih jauh tentang pengembalian bersyarat yang disebutkan secara singkat di https://github.com/golang/go/issues/32437#issuecomment -498947603.
Kelihatannya
return if f, err := os.Open("/my/file/path"); err != nil
akan lebih sesuai dengan tampilan if Go yang ada.

Jika kita menambahkan aturan untuk pernyataan return if bahwa
ketika ekspresi kondisi terakhir (seperti err != nil ) tidak ada,dan variabel terakhir dari deklarasi dalam pernyataan return if bertipe error ,maka nilai dari variabel terakhir akan secara otomatis dibandingkan dengan nil sebagai kondisi implisit.

Maka pernyataan return if dapat disingkat menjadi:
return if f, err := os.Open("my/file/path")

Yang sangat dekat dengan rasio signal-noise yang disediakan oleh try .
Jika kita mengubah return if menjadi try , menjadi
try f, err := os.Open("my/file/path")
Sekali lagi menjadi mirip dengan variasi lain yang diusulkan dari try di utas ini, setidaknya secara sintaksis.
Secara pribadi, saya masih lebih suka return if daripada try dalam hal ini karena ini membuat titik keluar dari suatu fungsi menjadi sangat eksplisit. Misalnya, ketika debugging saya sering menyorot kata kunci return di dalam editor untuk mengidentifikasi semua titik keluar dari fungsi besar.

Sayangnya, tampaknya tidak cukup membantu dengan ketidaknyamanan memasukkan debug logging juga.
Kecuali kami juga mengizinkan blok body untuk return if , seperti
Asli:

        return if f, err := os.Open("my/path") 

Saat men-debug:

-       return if f, err := os.Open("my/path") 
+       return if f, err := os.Open("my/path") {
+               fmt.Printf("DEBUG: os.Open: %s\n", err)
+       }

Arti dari blok tubuh return if sudah jelas, saya berasumsi. Ini akan dieksekusi sebelum defer dan kembali.

Yang mengatakan, saya tidak memiliki keluhan dengan pendekatan penanganan kesalahan yang ada di Go.
Saya lebih prihatin tentang bagaimana penambahan penanganan kesalahan baru akan berdampak pada kebaikan Go saat ini.

@velovix Kami sangat menyukai ide try dengan fungsi handler eksplisit sebagai argumen ke-2. Tetapi ada terlalu banyak pertanyaan yang tidak memiliki jawaban yang jelas, seperti yang dinyatakan oleh dokumen desain. Anda telah menjawab beberapa dari mereka dengan cara yang tampaknya masuk akal bagi Anda. Sangat mungkin (dan itu adalah pengalaman kami di dalam Tim Go), bahwa orang lain berpikir bahwa jawaban yang benar adalah jawaban yang sangat berbeda. Misalnya, Anda menyatakan bahwa argumen handler harus selalu diberikan, tetapi dapat berupa nil , untuk membuatnya eksplisit, kami tidak peduli dengan penanganan kesalahan. Sekarang apa yang terjadi jika seseorang memberikan nilai fungsi (bukan nil literal), dan nilai fungsi itu (disimpan dalam variabel) ternyata nihil? Dengan analogi dengan nilai nil eksplisit, tidak diperlukan penanganan. Tetapi orang lain mungkin berpendapat bahwa ini adalah bug dalam kode. Atau, sebagai alternatif, seseorang dapat mengizinkan argumen penangan bernilai nihil, tetapi kemudian suatu fungsi mungkin secara tidak konsisten menangani kesalahan dalam beberapa kasus dan tidak dalam kasus lain, dan tidak selalu jelas dari kode yang mana, karena tampaknya penangan selalu ada . Argumen lain adalah bahwa lebih baik memiliki deklarasi tingkat atas dari penangan kesalahan karena itu membuatnya sangat jelas bahwa fungsi memang menangani kesalahan. Oleh karena itu defer . Mungkin ada lebih.

Akan lebih baik untuk mempelajari lebih lanjut tentang kekhawatiran ini. Gaya pengkodean saat ini menggunakan pernyataan if untuk menguji kesalahan adalah sejelas mungkin. Sangat mudah untuk menambahkan informasi tambahan ke kesalahan, secara individual (untuk masing-masing jika). Seringkali masuk akal untuk menangani semua kesalahan yang terdeteksi dalam suatu fungsi dengan cara yang seragam, yang dapat dilakukan dengan penundaan - ini sudah dimungkinkan sekarang. Fakta bahwa kita sudah memiliki semua alat untuk penanganan kesalahan yang baik dalam bahasa, dan masalah konstruk penangan yang tidak ortogonal untuk ditunda, yang membuat kita meninggalkan mekanisme baru semata-mata untuk menambah kesalahan.

@griesemer - IIUC, Anda mengatakan bahwa untuk konteks kesalahan yang bergantung pada situs panggilan, pernyataan if saat ini baik-baik saja. Padahal, fungsi try baru ini berguna untuk kasus-kasus di mana menangani banyak kesalahan di satu tempat berguna.

Saya percaya kekhawatirannya adalah bahwa, walaupun hanya melakukan if err != nil { return err} mungkin baik-baik saja untuk beberapa kasus, biasanya disarankan untuk menghias kesalahan sebelum kembali. Dan proposal ini tampaknya membahas yang sebelumnya dan tidak berbuat banyak untuk yang terakhir. Yang pada dasarnya berarti orang akan didorong untuk menggunakan pola pengembalian yang mudah.

@agnivade Anda benar, proposal ini sama sekali tidak membantu dengan dekorasi kesalahan (tetapi untuk merekomendasikan penggunaan defer ). Salah satu alasannya adalah bahwa mekanisme bahasa untuk ini sudah ada. Segera setelah dekorasi kesalahan diperlukan, terutama atas dasar kesalahan individu, jumlah tambahan teks sumber untuk kode dekorasi membuat if kurang memberatkan dibandingkan. Ini adalah kasus di mana tidak ada dekorasi yang diperlukan, atau di mana dekorasi selalu sama, di mana boilerplate menjadi gangguan yang terlihat dan kemudian mengurangi kode penting.

Orang-orang sudah didorong untuk menggunakan pola pengembalian yang mudah, try atau tidak try , hanya ada sedikit untuk ditulis. Kalau dipikir-pikir, _satu-satunya cara untuk mendorong dekorasi kesalahan adalah membuatnya wajib_, karena apa pun dukungan bahasa yang tersedia, kesalahan dekorasi akan membutuhkan lebih banyak pekerjaan.

Salah satu cara untuk mempermanis kesepakatan adalah dengan hanya mengizinkan sesuatu seperti try (atau notasi pintasan analog lainnya) _jika_ handler eksplisit (mungkin kosong) disediakan di suatu tempat (perhatikan bahwa desain draf asli tidak memiliki persyaratan, baik).

Saya tidak yakin kami ingin melangkah sejauh ini. Biarkan saya menyatakan kembali bahwa banyak kode yang sangat bagus, katakanlah internal perpustakaan, tidak perlu menghiasi kesalahan di mana-mana. Tidak apa-apa untuk menyebarkan kesalahan dan menghiasnya tepat sebelum mereka meninggalkan titik masuk API, misalnya. (Faktanya, mendekorasinya di mana-mana hanya akan menyebabkan kesalahan yang terlalu didekorasi, dengan penyebab sebenarnya tersembunyi, mempersulit untuk menemukan kesalahan penting; sangat mirip dengan pencatatan yang terlalu bertele-tele dapat mempersulit untuk melihat apa yang sebenarnya terjadi).

Saya pikir kita juga bisa menambahkan fungsi tangkap , yang akan menjadi pasangan yang bagus, jadi:

func a() int {
  x := randInt()
  // let's assume that this is what recruiters should "fix" for us
  // or this happens in 3rd-party package.
  if x % 1337 != 0 {
    panic("not l33t enough")
  }
  return x
}

func b() error {
  // if a() panics, then x = 0, err = error{"not l33t enough"}
  x, err := catch(a())
  if err != nil {
    return err
  }
  sendSomewhereElse(x)
  return nil
}

// which could be simplified even further

func c() error {
  x := try(catch(a()))
  sendSomewhereElse(x)
  return nil
}

dalam contoh ini, catch() akan recover() panik dan return ..., panicValue .
tentu saja, kami memiliki kasus sudut yang jelas di mana kami memiliki fungsi, yang juga mengembalikan kesalahan. dalam hal ini saya pikir akan lebih mudah untuk hanya melewati nilai kesalahan.

jadi, pada dasarnya, Anda kemudian dapat menggunakan catch() untuk benar-benar memulihkan() panik dan mengubahnya menjadi kesalahan.
ini terlihat cukup lucu bagi saya, karena Go sebenarnya tidak memiliki pengecualian, tetapi dalam kasus ini kami memiliki pola try()-catch() yang cukup rapi, yang juga tidak akan meledakkan seluruh basis kode Anda dengan sesuatu seperti Java ( catch(Throwable) di Utama + throws LiterallyAnything ). Anda dapat dengan mudah memproses kepanikan seseorang seperti itu adalah kesalahan biasa. Saat ini saya memiliki sekitar 6mln+ LoC di Go dalam proyek saya saat ini, dan saya pikir ini akan menyederhanakan hal-hal setidaknya untuk saya.

@griesemer Terima kasih atas rekap diskusi Anda.

Saya melihat satu hal yang hilang di sana: beberapa orang berpendapat bahwa kita harus menunggu dengan fitur ini sampai kita memiliki obat generik, yang diharapkan akan memungkinkan kita untuk memecahkan masalah ini dengan cara yang lebih elegan.

Selain itu, saya juga menyukai saran @velovix , dan meskipun saya menghargai bahwa ini menimbulkan beberapa pertanyaan seperti yang dijelaskan dalam spesifikasi, saya pikir ini dapat dengan mudah dijawab dengan cara yang masuk akal, seperti yang sudah dilakukan oleh @velovix .

Sebagai contoh:

• Apa yang terjadi jika seseorang memberikan nilai fungsi (bukan literal nihil), dan nilai fungsi itu (disimpan dalam variabel) ternyata nihil? => Jangan menangani kesalahan, titik. Ini berguna jika penanganan kesalahan bergantung pada konteks dan variabel penangan diatur tergantung pada apakah penanganan kesalahan diperlukan atau tidak. Ini bukan bug, melainkan fitur. :)

• Argumen lain adalah bahwa lebih baik memiliki deklarasi tingkat atas dari penangan kesalahan karena itu membuatnya sangat jelas bahwa fungsi memang menangani kesalahan. => Jadi, tentukan pengendali kesalahan di bagian atas fungsi sebagai fungsi penutupan bernama dan gunakan itu, jadi juga sangat jelas bahwa kesalahan harus ditangani. Ini bukan masalah serius, lebih merupakan persyaratan gaya.

Apa kekhawatiran lain yang ada? Saya cukup yakin mereka semua dapat dijawab dengan cara yang sama dengan cara yang masuk akal.

Akhirnya, seperti yang Anda katakan, "salah satu cara untuk mempermanis kesepakatan adalah dengan hanya mengizinkan sesuatu seperti try (atau notasi pintasan analog apa pun) jika penangan eksplisit (mungkin kosong) disediakan di suatu tempat". Saya pikir jika kita ingin melanjutkan proposal ini, kita harus benar-benar mengambilnya "sejauh ini", untuk mendorong penanganan kesalahan yang tepat, "eksplisit lebih baik daripada implisit".

@griesemer

Sekarang apa yang terjadi jika seseorang memberikan nilai fungsi (bukan literal nihil), dan nilai fungsi itu (disimpan dalam variabel) ternyata nihil? Dengan analogi dengan nilai nil eksplisit, penanganan tidak diperlukan. Tetapi orang lain mungkin berpendapat bahwa ini adalah bug dalam kode.

Secara teori ini memang tampak seperti gotcha potensial, meskipun saya mengalami kesulitan mengkonseptualisasikan situasi yang masuk akal di mana seorang pawang akhirnya menjadi nihil secara tidak sengaja. Saya membayangkan bahwa penangan paling sering berasal dari fungsi utilitas yang didefinisikan di tempat lain, atau sebagai penutupan yang ditentukan dalam fungsi itu sendiri. Tak satu pun dari ini cenderung menjadi nihil secara tak terduga. Anda secara teoritis dapat memiliki skenario di mana fungsi handler diedarkan sebagai argumen untuk fungsi lain, tetapi bagi saya tampaknya agak tidak masuk akal. Mungkin ada pola seperti ini yang tidak saya sadari.

Argumen lain adalah bahwa lebih baik memiliki deklarasi tingkat atas dari penangan kesalahan karena itu membuatnya sangat jelas bahwa fungsi memang menangani kesalahan. Oleh karena itu defer .

Seperti yang disebutkan @beoran , mendefinisikan handler sebagai penutupan di dekat bagian atas fungsi akan terlihat sangat mirip dalam gaya, dan itulah yang secara pribadi saya harapkan orang akan menggunakan handler paling umum. Meskipun saya menghargai kejelasan yang dimenangkan oleh fakta bahwa semua fungsi yang menangani kesalahan akan menggunakan defer , itu mungkin menjadi kurang jelas ketika suatu fungsi perlu berputar dalam strategi penanganan kesalahannya di tengah fungsi. Kemudian, akan ada dua defer untuk dilihat dan pembaca harus mempertimbangkan bagaimana mereka akan berinteraksi satu sama lain. Ini adalah situasi di mana saya percaya argumen handler akan lebih jelas dan ergonomis, dan saya pikir ini akan menjadi skenario _relatif_ umum.

Apakah mungkin untuk membuatnya bekerja tanpa tanda kurung?

Yaitu sesuatu seperti:
a := try func(some)

@Cyberax - Seperti yang telah disebutkan di atas, sangat penting bagi Anda untuk membaca dokumen desain dengan cermat sebelum memposting. Karena ini adalah masalah lalu lintas tinggi, dengan banyak orang berlangganan.

Doc membahas operator vs fungsi secara rinci.

Saya suka ini lebih dari yang saya suka versi agustus.

Saya pikir banyak umpan balik negatif, yang tidak langsung bertentangan dengan pengembalian tanpa kata kunci return , dapat diringkas dalam dua poin:

1. orang tidak suka parameter hasil bernama, yang akan diperlukan dalam banyak kasus
2. itu mencegah menambahkan konteks terperinci ke kesalahan

Lihat misalnya:

• https://github.com/golang/go/issues/32437#issuecomment -498937169
• https://github.com/golang/go/issues/32437#issuecomment -498967099
• https://github.com/golang/go/issues/32437#issuecomment -499194787
• https://github.com/golang/go/issues/32437#issuecomment -499309304

Adapun bantahan atas kedua keberatan tersebut masing-masing adalah:

1. "kami memutuskan bahwa [parameter hasil bernama] baik-baik saja"
2. "Tidak ada yang akan membuat Anda menggunakan try " / itu tidak akan sesuai untuk 100% kasus

Saya tidak punya apa-apa untuk dikatakan tentang 1 (saya tidak merasa kuat tentang itu). Tetapi mengenai 2 saya perhatikan bahwa proposal agustus tidak memiliki masalah ini, sebagian besar proposal tandingan juga tidak memiliki masalah ini.

Secara khusus baik tryf counter-proposal (yang telah diposting secara independen dua kali di utas ini) maupun try(X, handlefn) counter-proposal (yang merupakan bagian dari iterasi desain) tidak memiliki masalah ini.

Saya pikir sulit untuk membantah bahwa try , sebagaimana adanya, akan mendorong orang menjauh dari kesalahan dekorasi dengan konteks yang relevan dan menuju dekorasi kesalahan per fungsi generik tunggal.

Karena alasan ini, saya pikir ada baiknya mencoba mengatasi masalah ini dan saya ingin mengusulkan solusi yang memungkinkan:

1. Saat ini parameter defer hanya dapat berupa pemanggilan fungsi atau metode. Izinkan defer juga memiliki nama fungsi atau literal fungsi, mis

defer func(...) {...}
defer packageName.functionName

1. Ketika panik atau penangguhan menghadapi jenis penangguhan ini, mereka akan memanggil fungsi yang melewati nilai nol untuk semua parameternya

2. Izinkan try memiliki lebih dari satu parameter

3. Ketika try bertemu dengan tipe penangguhan baru, ia akan memanggil fungsi yang meneruskan pointer ke nilai kesalahan sebagai parameter pertama diikuti oleh semua parameter try sendiri, kecuali yang pertama.

Misalnya, diberikan:

func errorfn() error {
    return errors.New("an error")
}


func f(fail bool) {
    defer func(err *error, a, b, c int) {
        fmt.Printf("a=%d b=%d c=%d\n", a, b, c)
    }
    if fail {
        try(errorfn, 1, 2, 3)
    }
}

berikut akan terjadi:

f(false)        // prints "a=0 b=0 c=0"
f(true)         // prints "a=1 b=2 c=3"

Kode di https://github.com/golang/go/issues/32437#issuecomment -499309304 oleh @zeebo kemudian dapat ditulis ulang sebagai:

func (c *Config) Build() error {
    defer func(err *error, msg string, args ...interface{}) {
        if *err == nil || msg == "" {
            return
        }
        *err = errors.WithMessagef(err, msg, args...)
    }
    pkgPath := try(c.load(), "load config dir")

    b := bytes.NewBuffer(nil)
    try(templates.ExecuteTemplate(b, "main", c), "execute main template")

    buf := try(format.Source(b.Bytes()), "format main template")

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    try(ioutil.WriteFile(target, buf, 0644), "write file %s", target)
    // ...
}

Dan mendefinisikan ErrorHandlef sebagai:

func HandleErrorf(err *error, format string, args ...interface{}) {
        if *err != nil && format != "" {
                *err = fmt.Errorf(format + ": %v", append(args, *err)...)
        }
}

akan memberikan tryf yang banyak dicari semua orang secara gratis, tanpa menarik string format fmt -style ke dalam bahasa inti.

Fitur ini kompatibel ke belakang karena defer tidak mengizinkan ekspresi fungsi sebagai argumennya. Itu tidak memperkenalkan kata kunci baru.
Perubahan yang perlu dilakukan untuk mengimplementasikannya, selain yang diuraikan di https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md , adalah:

1. ajari parser tentang jenis penangguhan baru
2. ubah pemeriksa tipe untuk memeriksa bahwa di dalam suatu fungsi semua penangguhan yang memiliki fungsi sebagai parameter (bukan panggilan) juga memiliki tanda tangan yang sama
3. ubah pemeriksa tipe untuk memeriksa apakah parameter yang diteruskan ke try cocok dengan tanda tangan fungsi yang diteruskan ke defer
4. ubah backend (?) untuk menghasilkan panggilan deferproc yang sesuai
5. ubah implementasi try untuk menyalin argumennya ke dalam argumen dari panggilan yang ditangguhkan ketika menemukan panggilan yang ditangguhkan oleh jenis penangguhan yang baru.

Setelah kerumitan desain draf check/handle , saya terkejut melihat proposal yang jauh lebih sederhana dan pragmatis ini mendarat meskipun saya kecewa karena ada begitu banyak penolakan terhadapnya.

Diakui banyak penolakan datang dari orang-orang yang cukup senang dengan verbositas saat ini (posisi yang sangat masuk akal untuk diambil) dan yang mungkin tidak akan benar-benar menerima proposal apa pun untuk meringankannya. Bagi kita semua, saya pikir proposal ini tepat sasaran karena sederhana dan mirip Go, tidak mencoba melakukan terlalu banyak dan menyesuaikan diri dengan baik dengan teknik penanganan kesalahan yang ada di mana Anda selalu dapat mundur jika try tidak melakukan persis seperti yang Anda inginkan.

Mengenai beberapa poin tertentu:

1. Satu-satunya hal yang saya tidak suka tentang proposal adalah kebutuhan untuk memiliki parameter pengembalian kesalahan bernama ketika defer digunakan tetapi, karena itu, saya tidak dapat memikirkan solusi lain yang tidak akan bertentangan dengan cara kerja bahasa lainnya. Jadi saya pikir kita hanya harus menerima ini jika proposal diadopsi.

2. Sangat disayangkan bahwa try tidak cocok dengan paket pengujian untuk fungsi yang tidak mengembalikan nilai kesalahan. Solusi pilihan saya sendiri untuk ini adalah memiliki fungsi bawaan kedua (mungkin ptry atau must ) yang selalu panik daripada kembali saat menemui kesalahan non-nihil dan yang karenanya dapat menjadi digunakan dengan fungsi yang disebutkan di atas (termasuk main ). Meskipun ide ini telah ditolak dalam iterasi proposal saat ini, saya membentuk kesan bahwa itu adalah 'panggilan dekat' dan karena itu mungkin memenuhi syarat untuk dipertimbangkan kembali.

3. Saya pikir akan sulit bagi orang-orang untuk memahami apa yang dilakukan go try(f) atau defer try(f) dan karena itu yang terbaik adalah melarang mereka sama sekali.

4. Saya setuju dengan mereka yang berpikir bahwa teknik penanganan kesalahan yang ada akan terlihat kurang bertele-tele jika go fmt tidak menulis ulang satu baris pernyataan if . Secara pribadi, saya lebih suka aturan sederhana bahwa ini akan diizinkan untuk _any_ pernyataan tunggal if apakah berkaitan dengan penanganan kesalahan atau tidak. Sebenarnya saya tidak pernah bisa mengerti mengapa ini saat ini tidak diizinkan saat menulis fungsi satu baris di mana tubuh ditempatkan pada baris yang sama dengan deklarasi yang diizinkan.

Dalam kasus kesalahan dekorasi

func myfunc()( err error){
try(thing())
defer func(){
err = errors.Wrap(err,"more context")
}()
}

Ini terasa jauh lebih bertele-tele dan menyakitkan daripada paradigma yang ada, dan tidak sesingkat check/handle. Varian try() non-wrapping lebih ringkas, tetapi rasanya orang akan berakhir menggunakan campuran try, dan kesalahan biasa kembali. Saya tidak yakin saya menyukai ide pencampuran coba dan pengembalian kesalahan sederhana, tetapi saya benar-benar menjual kesalahan dekorasi (dan menantikan Is/As). Buat saya berpikir bahwa meskipun ini secara sintaksis rapi, saya tidak yakin saya ingin benar-benar menggunakannya. check/handle merasakan sesuatu yang akan saya peluk dengan lebih seksama.

Saya sangat menyukai kesederhanaan ini dan pendekatan "lakukan satu hal dengan baik". Dalam penerjemah GoAWK saya, ini akan sangat membantu -- saya memiliki sekitar 100 if err != nil { return nil } konstruksi yang akan disederhanakan dan dirapikan, dan itu ada dalam basis kode yang cukup kecil.

Saya telah membaca pembenaran proposal untuk menjadikannya sebagai bawaan daripada kata kunci, dan intinya tidak harus menyesuaikan pengurai. Tetapi bukankah itu sedikit menyusahkan bagi penulis kompiler dan perkakas, sedangkan memiliki parens tambahan dan masalah keterbacaan yang terlihat-seperti-fungsi-tetapi-bukan-akan menjadi sesuatu yang semua pembuat kode dan kode Go- pembaca harus bertahan. Menurut pendapat saya argumen (alasan? :-) bahwa "tetapi panic() mengontrol aliran" tidak memotongnya, karena kepanikan dan pemulihan pada dasarnya adalah, luar biasa , sedangkan try() akan menjadi penanganan kesalahan normal dan aliran kontrol.

Saya pasti akan menghargainya bahkan jika ini berjalan apa adanya, tetapi preferensi kuat saya adalah agar aliran kontrol normal menjadi jelas, yaitu, dilakukan melalui kata kunci.

Saya mendukung proposal ini. Itu menghindari reservasi terbesar saya tentang proposal sebelumnya: non-ortogonalitas handle sehubungan dengan defer .

Saya ingin menyebutkan dua aspek yang menurut saya tidak disorot di atas.

Pertama, meskipun proposal ini tidak memudahkan untuk menambahkan teks kesalahan khusus konteks ke kesalahan, ini _memudahkan untuk menambahkan informasi pelacakan kesalahan bingkai tumpukan ke kesalahan: https://play.golang.org/p /YL1MoqR08E6

Kedua, try bisa dibilang merupakan solusi yang adil untuk sebagian besar masalah yang mendasari https://github.com/golang/go/issues/19642. Untuk mengambil contoh dari masalah itu, Anda dapat menggunakan try untuk menghindari penulisan semua nilai yang dikembalikan setiap kali. Ini juga berpotensi berguna saat mengembalikan tipe struct berdasarkan nilai dengan nama panjang.

func (f *Font) viewGlyphData(b *Buffer, x GlyphIndex) (buf []byte, offset, length uint32, err error) {
    xx := int(x)
    if f.NumGlyphs() <= xx {
        try(ErrNotFound)
    }
    i := f.cached.locations[xx+0]
    j := f.cached.locations[xx+1]
    if j < i {
        try(errInvalidGlyphDataLength)
    }
    if j-i > maxGlyphDataLength {
        try(errUnsupportedGlyphDataLength)
    }
    buf, err = b.view(&f.src, int(i), int(j-i))
    return buf, i, j - i, err
}

Saya juga menyukai proposal ini.

Dan saya punya permintaan.

Seperti make , dapatkah kita mengizinkan try untuk mengambil sejumlah variabel parameter

• coba (p):
  seperti di atas.
  nilai kesalahan pengembalian adalah wajib (sebagai parameter pengembalian terakhir).
  MODEL PENGGUNAAN PALING UMUM
• coba (f, doPanic bool):
  seperti di atas, tetapi jika doPanic, maka panic(err) alih-alih kembali.
  Dalam mode ini, nilai kesalahan pengembalian tidak diperlukan.
• coba (p, fn):
  seperti di atas, tetapi panggil fn(err) sebelum kembali.
  Dalam mode ini, nilai kesalahan pengembalian tidak diperlukan.

Dengan cara ini, ini adalah salah satu bawaan yang dapat menangani semua kasus penggunaan, sambil tetap eksplisit. Keuntungannya:

• selalu eksplisit - tidak perlu menyimpulkan apakah akan panik atau mengatur kesalahan dan kembali
• mendukung penangan khusus konteks (tetapi tidak ada rantai penangan)
• mendukung kasus penggunaan di mana tidak ada variabel pengembalian kesalahan
• mendukung must(...) semantik

Meskipun if err !=nil { return ... err } berulang-ulang jelas merupakan kegagapan yang buruk, saya setuju dengan itu
yang menganggap proposal try() sangat rendah dalam keterbacaan dan agak tidak eksplisit.
Penggunaan pengembalian bernama juga bermasalah.

Jika penataan seperti ini diperlukan, mengapa tidak try(err) sebagai gula sintaksis untuk
if err !=nil { return err } :

file, err := os.Open("file.go")
try(err)

untuk

file, err := os.Open("file.go")
if err != nil {
   return err
}

Dan jika ada lebih dari satu nilai kembalian, try(err) dapat return t1, ... tn, err
di mana t1, ... tn adalah nilai nol dari nilai balik lainnya.

Saran ini dapat meniadakan kebutuhan akan nilai pengembalian bernama dan menjadi,
menurut saya, lebih mudah dipahami dan lebih mudah dibaca.

Bahkan lebih baik, saya pikir akan menjadi:

file, try(err) := os.Open("file.go")

Atau bahkan

file, err? := os.Open("file.go")

Yang terakhir ini kompatibel ke belakang (? Saat ini tidak diizinkan di pengidentifikasi).

(Saran ini terkait dengan https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring-themes. Tetapi contoh tema yang berulang tampak berbeda karena itu pada tahap ketika pegangan eksplisit masih dibahas alih-alih pergi itu untuk menunda.)

Terima kasih kepada tim go atas proposal yang menarik dan hati-hati ini.

@rogpeppe berkomentar jika try secara otomatis menambahkan bingkai tumpukan, bukan saya, saya setuju dengan itu tidak menambah konteks.

@aarzilli - Jadi menurut proposal Anda, apakah klausa penangguhan wajib setiap kali kami memberikan parameter tambahan ke tryf ?

Apa yang terjadi jika saya melakukannya?

try(ioutil.WriteFile(target, buf, 0644), "write file %s", target)

dan tidak menulis fungsi penangguhan?

@agnivade

Apa yang terjadi jika saya melakukan (...) dan tidak menulis fungsi penangguhan?

kesalahan pengetikan.

Menurut pendapat saya, menggunakan try untuk menghindari penulisan semua nilai yang dikembalikan sebenarnya hanyalah pemogokan lain terhadapnya.

func (f *Font) viewGlyphData(b *Buffer, x GlyphIndex) (buf []byte, offset, length uint32, err error) {
    xx := int(x)
    if f.NumGlyphs() <= xx {
        try(ErrNotFound)
    }
    //...

Saya sepenuhnya memahami keinginan untuk menghindari keharusan menulis return nil, 0, 0, ErrNotFound , tetapi saya lebih suka menyelesaikannya dengan cara lain.

Kata try tidak berarti "kembali". Dan begitulah yang digunakan di sini. Saya sebenarnya lebih suka proposal berubah sehingga try tidak dapat mengambil nilai error secara langsung, karena saya tidak pernah ingin ada orang yang menulis kode seperti itu ^^ . Itu salah baca. Jika Anda menunjukkan kode itu kepada seorang pemula, mereka tidak akan tahu apa yang coba dilakukan.

Jika kita menginginkan cara untuk mengembalikan default dan nilai kesalahan dengan mudah, mari kita selesaikan secara terpisah. Mungkin bawaan lain seperti

return default(ErrNotFound)

Setidaknya itu terbaca dengan semacam logika.

Tapi jangan menyalahgunakan try untuk menyelesaikan beberapa masalah lain.

@natefinch jika try builtin bernama check seperti dalam proposal asli, itu akan menjadi check(err) yang terbaca jauh lebih baik, imo.

Mengesampingkan itu, saya tidak tahu apakah menulis try(err) benar-benar merupakan penyalahgunaan. Itu keluar dari definisi dengan bersih. Tetapi, di sisi lain, itu juga berarti bahwa ini sah:

a, b := try(1, f(), err)

Saya kira masalah utama saya dengan try adalah bahwa itu benar-benar hanya panic yang hanya naik satu tingkat... kecuali bahwa tidak seperti panik, ini adalah ekspresi, bukan pernyataan, sehingga Anda dapat menyembunyikan itu di tengah-tengah pernyataan di suatu tempat. Itu hampir membuatnya lebih buruk daripada panik.

@natefinch Jika Anda mengonsepnya seperti kepanikan yang naik satu tingkat dan kemudian melakukan hal-hal lain, tampaknya sangat berantakan. Namun, saya mengkonseptualisasikannya secara berbeda. Fungsi yang mengembalikan kesalahan di Go secara efektif mengembalikan Hasil, untuk secara longgar meminjam dari terminologi Rust. try adalah utilitas yang membongkar hasil dan mengembalikan "hasil kesalahan" jika error != nil , atau membongkar bagian T dari hasil jika error == nil .

Tentu saja, di Go kita sebenarnya tidak memiliki objek hasil, tetapi secara efektif polanya sama dan try tampak seperti kodifikasi alami dari pola itu. Saya percaya bahwa solusi apa pun untuk masalah ini harus mengkodifikasi beberapa aspek penanganan kesalahan, dan try s mengambilnya tampaknya masuk akal bagi saya. Saya dan orang lain menyarankan untuk sedikit memperluas kemampuan try agar lebih sesuai dengan pola penanganan kesalahan Go yang ada, tetapi konsep dasarnya tetap sama.

@ugorji Varian try(f, bool) yang Anda usulkan terdengar seperti must dari #32219.

@ugorji Varian try(f, bool) yang Anda usulkan terdengar seperti must dari #32219.

Ya itu. Saya hanya merasa ketiga kasus dapat ditangani dengan fungsi bawaan tunggal, dan memenuhi semua kasus penggunaan dengan elegan.

Karena try() sudah ajaib, dan menyadari nilai pengembalian kesalahan, dapatkah itu ditambah untuk juga mengembalikan pointer ke nilai itu ketika dipanggil dalam bentuk nullary (argumen nol)? Itu akan menghilangkan kebutuhan untuk pengembalian bernama, dan saya percaya, membantu untuk menghubungkan secara visual dari mana kesalahan diharapkan berasal dalam pernyataan penangguhan. Sebagai contoh:

func foo() error {
  defer fmt.HandleErrorf(try(), "important foo context info")
  try(bar())
  try(baz())
  try(etc())
}

@ugorji
Saya pikir boolean pada try(f, bool) akan membuatnya sulit dibaca dan mudah dilewatkan. Saya suka proposal Anda, tetapi untuk kasus panik, saya pikir itu bisa ditinggalkan bagi pengguna untuk menulisnya di dalam handler dari poin ketiga Anda, misalnya try(f(), func(err error) { panic('at the disco'); }) , ini membuatnya lebih eksplisit bagi pengguna daripada try(f(), true) tersembunyi

@ugorji
Saya pikir boolean pada try(f, bool) akan membuatnya sulit dibaca dan mudah dilewatkan. Saya suka proposal Anda, tetapi untuk kasus panik, saya pikir itu bisa ditinggalkan bagi pengguna untuk menulisnya di dalam handler dari poin ketiga Anda, misalnya try(f(), func(err error) { panic('at the disco'); }) , ini membuatnya lebih eksplisit bagi pengguna daripada try(f(), true) tersembunyi

Kalau dipikir-pikir lebih jauh, saya cenderung setuju dengan posisi dan alasan Anda, dan tetap terlihat elegan sebagai one-liner.

@patrick-nyt masih merupakan pendukung _assignment syntax_ untuk memicu tes nihil, di https://github.com/golang/go/issues/32437#issuecomment -499533464

Konsep ini muncul dalam 13 tanggapan terpisah untuk memeriksa/menangani proposal
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

f, ?return := os.Open(...)
f, ?panic  := os.Open(...)

Mengapa? Karena terbaca seperti Go 1, sedangkan try() dan check tidak.

https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md#draft -design

Satu keberatan untuk try tampaknya adalah ekspresi. Misalkan ada pernyataan postfix unary ? yang berarti return jika tidak nil. Berikut adalah contoh kode standar (dengan asumsi bahwa paket tertunda yang saya usulkan ditambahkan):

func CopyFile(src, dst string) error {
    var err error // Don't need a named return because err is explicitly named
    defer deferred.Annotate(&err, "copy %s %s", src, dst)

    r, err := os.Open(src)
    err?
    defer deferred.AnnotatedExec(&err, r.Close)

    w, err := os.Create(dst)
    err?
    defer deferred.AnnotatedExec(&err, r.Close)

    defer deferred.Cond(&err, func(){ os.Remove(dst) })
    _, err = io.Copy(w, r)

    return err
}

Contoh pgStore:

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    err?

    defer deferred.Cond(&err, func(){ tx.Rollback() })

    var res int64 
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    // tricky bit: this would not change the value of err 
    // but the deferred.Cond would still be triggered by err being set before
    deferred.Format(err, "insert table")?

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    deferred.Format(err, "insert table2")?

    return tx.Commit()
}

Saya suka ini dari @jargv :

Karena try() sudah ajaib, dan menyadari nilai pengembalian kesalahan, dapatkah itu ditambah untuk juga mengembalikan pointer ke nilai itu saat dipanggil dalam bentuk nullary (argumen nol)? Itu akan menghilangkan kebutuhan untuk pengembalian bernama

Tetapi alih-alih membebani nama try berdasarkan jumlah argumen, saya pikir mungkin ada keajaiban lain yang ada di dalamnya, katakan reterr atau sesuatu.

Saya telah diberi pengarahan melalui beberapa paket yang sangat sering digunakan, mencari kode go yang "menderita" dari penanganan err tetapi harus dipikirkan dengan matang sebelum ditulis, mencoba mencari tahu "keajaiban" apa yang akan dilakukan oleh try() yang diusulkan.
Saat ini, kecuali saya salah memahami proposal, banyak di antaranya (misalnya penanganan kesalahan yang tidak terlalu mendasar) tidak akan mendapatkan banyak, atau harus tetap menggunakan gaya penanganan kesalahan "lama".
Contoh dari net/http/request.go:

func (r *Request) write(w io.Writer, usingProxy bool, extraHeaders Header, waitForContinue func() bool) (err error) {
`

trace := httptrace.ContextClientTrace(r.Context())
if trace != nil && trace.WroteRequest != nil {
    defer func() {
        trace.WroteRequest(httptrace.WroteRequestInfo{
            Err: err,
        })
    }()
}

// Find the target host. Prefer the Host: header, but if that
// is not given, use the host from the request URL.
//
// Clean the host, in case it arrives with unexpected stuff in it.
host := cleanHost(r.Host)
if host == "" {
    if r.URL == nil {
        return errMissingHost
    }
    host = cleanHost(r.URL.Host)
}

// According to RFC 6874, an HTTP client, proxy, or other
// intermediary must remove any IPv6 zone identifier attached
// to an outgoing URI.
host = removeZone(host)

ruri := r.URL.RequestURI()
if usingProxy && r.URL.Scheme != "" && r.URL.Opaque == "" {
    ruri = r.URL.Scheme + "://" + host + ruri
} else if r.Method == "CONNECT" && r.URL.Path == "" {
    // CONNECT requests normally give just the host and port, not a full URL.
    ruri = host
    if r.URL.Opaque != "" {
        ruri = r.URL.Opaque
    }
}
if stringContainsCTLByte(ruri) {
    return errors.New("net/http: can't write control character in Request.URL")
}
// TODO: validate r.Method too? At least it's less likely to
// come from an attacker (more likely to be a constant in
// code).

// Wrap the writer in a bufio Writer if it's not already buffered.
// Don't always call NewWriter, as that forces a bytes.Buffer
// and other small bufio Writers to have a minimum 4k buffer
// size.
var bw *bufio.Writer
if _, ok := w.(io.ByteWriter); !ok {
    bw = bufio.NewWriter(w)
    w = bw
}

_, err = fmt.Fprintf(w, "%s %s HTTP/1.1\r\n", valueOrDefault(r.Method, "GET"), ruri)
if err != nil {
    return err
}

// Header lines
_, err = fmt.Fprintf(w, "Host: %s\r\n", host)
if err != nil {
    return err
}
if trace != nil && trace.WroteHeaderField != nil {
    trace.WroteHeaderField("Host", []string{host})
}

// Use the defaultUserAgent unless the Header contains one, which
// may be blank to not send the header.
userAgent := defaultUserAgent
if r.Header.has("User-Agent") {
    userAgent = r.Header.Get("User-Agent")
}
if userAgent != "" {
    _, err = fmt.Fprintf(w, "User-Agent: %s\r\n", userAgent)
    if err != nil {
        return err
    }
    if trace != nil && trace.WroteHeaderField != nil {
        trace.WroteHeaderField("User-Agent", []string{userAgent})
    }
}

// Process Body,ContentLength,Close,Trailer
tw, err := newTransferWriter(r)
if err != nil {
    return err
}
err = tw.writeHeader(w, trace)
if err != nil {
    return err
}

err = r.Header.writeSubset(w, reqWriteExcludeHeader, trace)
if err != nil {
    return err
}

if extraHeaders != nil {
    err = extraHeaders.write(w, trace)
    if err != nil {
        return err
    }
}

_, err = io.WriteString(w, "\r\n")
if err != nil {
    return err
}

if trace != nil && trace.WroteHeaders != nil {
    trace.WroteHeaders()
}

// Flush and wait for 100-continue if expected.
if waitForContinue != nil {
    if bw, ok := w.(*bufio.Writer); ok {
        err = bw.Flush()
        if err != nil {
            return err
        }
    }
    if trace != nil && trace.Wait100Continue != nil {
        trace.Wait100Continue()
    }
    if !waitForContinue() {
        r.closeBody()
        return nil
    }
}

if bw, ok := w.(*bufio.Writer); ok && tw.FlushHeaders {
    if err := bw.Flush(); err != nil {
        return err
    }
}

// Write body and trailer
err = tw.writeBody(w)
if err != nil {
    if tw.bodyReadError == err {
        err = requestBodyReadError{err}
    }
    return err
}

if bw != nil {
    return bw.Flush()
}
return nil

}
`

atau seperti yang digunakan dalam pengujian menyeluruh seperti pprof/profile/profile_test.go:
`
func checkAggregation(prof *Profil, a *aggTest) kesalahan {
// Periksa apakah jumlah total sampel untuk baris dipertahankan.
jumlah := int64(0)

samples := make(map[string]bool)
for _, sample := range prof.Sample {
    tb := locationHash(sample)
    samples[tb] = true
    total += sample.Value[0]
}

if total != totalSamples {
    return fmt.Errorf("sample total %d, want %d", total, totalSamples)
}

// Check the number of unique sample locations
if a.rows != len(samples) {
    return fmt.Errorf("number of samples %d, want %d", len(samples), a.rows)
}

// Check that all mappings have the right detail flags.
for _, m := range prof.Mapping {
    if m.HasFunctions != a.function {
        return fmt.Errorf("unexpected mapping.HasFunctions %v, want %v", m.HasFunctions, a.function)
    }
    if m.HasFilenames != a.fileline {
        return fmt.Errorf("unexpected mapping.HasFilenames %v, want %v", m.HasFilenames, a.fileline)
    }
    if m.HasLineNumbers != a.fileline {
        return fmt.Errorf("unexpected mapping.HasLineNumbers %v, want %v", m.HasLineNumbers, a.fileline)
    }
    if m.HasInlineFrames != a.inlineFrame {
        return fmt.Errorf("unexpected mapping.HasInlineFrames %v, want %v", m.HasInlineFrames, a.inlineFrame)
    }
}

// Check that aggregation has removed finer resolution data.
for _, l := range prof.Location {
    if !a.inlineFrame && len(l.Line) > 1 {
        return fmt.Errorf("found %d lines on location %d, want 1", len(l.Line), l.ID)
    }

    for _, ln := range l.Line {
        if !a.fileline && (ln.Function.Filename != "" || ln.Line != 0) {
            return fmt.Errorf("found line %s:%d on location %d, want :0",
                ln.Function.Filename, ln.Line, l.ID)
        }
        if !a.function && (ln.Function.Name != "") {
            return fmt.Errorf(`found file %s location %d, want ""`,
                ln.Function.Name, l.ID)
        }
    }
}

return nil

}
`
Ini adalah dua contoh yang dapat saya pikirkan di mana orang akan mengatakan: "Saya ingin opsi penanganan kesalahan yang lebih baik"

Adakah yang bisa mendemonstrasikan bagaimana ini akan meningkat menggunakan try() ?

Saya sebagian besar mendukung proposal ini.

Perhatian utama saya, yang dibagikan dengan banyak komentator, adalah tentang parameter hasil bernama. Proposal saat ini tentu saja mendorong lebih banyak penggunaan parameter hasil bernama dan saya pikir itu akan menjadi kesalahan. Saya tidak percaya ini hanya masalah gaya seperti yang dinyatakan oleh proposal: hasil bernama adalah fitur halus dari bahasa yang, dalam banyak kasus, membuat kode lebih rawan bug atau kurang jelas. Setelah ~8 tahun membaca dan menulis kode Go, saya benar-benar hanya menggunakan parameter hasil bernama untuk dua tujuan:

• Dokumentasi parameter hasil
• Memanipulasi nilai hasil (biasanya error ) di dalam defer

Untuk menyerang masalah ini dari arah yang baru, inilah ide yang menurut saya tidak sejalan dengan apa pun yang telah dibahas dalam dokumen desain atau utas komentar masalah ini. Sebut saja "penangguhan kesalahan":

Izinkan penangguhan digunakan untuk memanggil fungsi dengan parameter kesalahan implisit.

Jadi jika Anda memiliki fungsi

func f(err error, t1 T1, t2 T2, ..., tn Tn) error

Kemudian, dalam fungsi g di mana parameter hasil terakhir memiliki tipe error (yaitu, fungsi apa pun di mana try saya digunakan), panggilan ke f dapat ditangguhkan sebagai berikut:

func g() (R0, R0, ..., error) {
    defer f(t0, t1, ..., tn) // err is implicit
}

Semantik dari penangguhan kesalahan adalah:

1. Panggilan yang ditangguhkan ke f dipanggil dengan parameter hasil terakhir g sebagai parameter input pertama f
2. f hanya dipanggil jika kesalahan itu tidak nihil
3. Hasil f ditetapkan ke parameter hasil terakhir g

Jadi untuk menggunakan contoh dari dokumen desain penanganan kesalahan lama, menggunakan penangguhan kesalahan dan coba, kita bisa melakukannya

func printSum(a, b string) error {
    defer func(err error) error {
        return fmt.Errorf("printSum(%q + %q): %v", a, b, err)
    }()
    x := try(strconv.Atoi(a))
    y := try(strconv.Atoi(b))
    fmt.Println("result:", x+y)
    return nil
}

Begini cara HandleErrorf akan bekerja:

func printSum(a, b string) error {
    defer handleErrorf("printSum(%q + %q)", a, b)
    x := try(strconv.Atoi(a))
    y := try(strconv.Atoi(b))
    fmt.Println("result:", x+y)
    return nil
}

func handleErrorf(err error, format string, args ...interface{}) error {
    return fmt.Errorf(format+": %v", append(args, err)...)
}

Satu kasus sudut yang perlu diselesaikan adalah bagaimana menangani kasus-kasus di mana tidak jelas bentuk penangguhan mana yang kita gunakan. Saya pikir itu hanya terjadi dengan fungsi (sangat tidak biasa) dengan tanda tangan seperti ini:

func(error, ...error) error

Tampaknya masuk akal untuk mengatakan bahwa kasus ini ditangani dengan cara non-error-defer (dan ini mempertahankan kompatibilitas ke belakang).

Memikirkan ide ini selama beberapa hari terakhir, ini sedikit ajaib, tetapi penghindaran parameter hasil yang disebutkan adalah keuntungan besar yang menguntungkannya. Karena try mendorong lebih banyak penggunaan defer untuk manipulasi kesalahan, masuk akal bahwa defer dapat diperluas agar lebih sesuai dengan tujuan itu. Juga, ada simetri tertentu antara try dan penangguhan kesalahan.

Akhirnya, penangguhan kesalahan berguna hari ini bahkan tanpa mencoba, karena mereka menggantikan penggunaan parameter hasil bernama untuk memanipulasi pengembalian kesalahan. Misalnya, ini adalah versi yang diedit dari beberapa kode asli:

// GetMulti retrieves multiple files through the cache at once and returns its
// results as a slice parallel to the input.
func (c *FileCache) GetMulti(keys []string) (_ []*File, err error) {
    files := make([]*file, len(keys))

    defer func() {
        if err != nil {
            // Return any successfully retrieved files.
            for _, f := range files {
                if f != nil {
                    c.put(f)
                }
            }
        }
    }()

    // ...
}

Dengan penangguhan kesalahan, ini menjadi:

// GetMulti retrieves multiple files through the cache at once and returns its
// results as a slice parallel to the input.
func (c *FileCache) GetMulti(keys []string) ([]*File, error) {
    files := make([]*file, len(keys))

    defer func(err error) error {
        // Return any successfully retrieved files.
        for _, f := range files {
            if f != nil {
                c.put(f)
            }
        }
        return err
    }()

    // ...
}

@beoran Mengenai komentar Anda bahwa kami harus menunggu obat generik. Obat generik tidak akan membantu di sini - harap baca FAQ .

Mengenai saran Anda tentang 2-argumen @velovix try 's perilaku default: Seperti yang saya katakan sebelumnya , gagasan Anda tentang apa pilihan yang jelas masuk akal adalah mimpi buruk orang lain.

Bolehkah saya menyarankan agar kita melanjutkan diskusi ini setelah konsensus luas berkembang bahwa try dengan penangan kesalahan eksplisit adalah ide yang lebih baik daripada try minimal saat ini. Pada saat itu masuk akal untuk membahas poin-poin bagus dari desain semacam itu.

(Saya suka memiliki handler, dalam hal ini. Ini adalah salah satu proposal kami sebelumnya. Dan jika kita mengadopsi try apa adanya, kita masih bisa bergerak menuju try dengan handler di depan -cara yang kompatibel - setidaknya jika handler adalah opsional. Tapi mari kita ambil satu langkah pada satu waktu.)

@aarzilli Terima kasih atas saran Anda.

Selama kesalahan dekorasi adalah opsional, orang akan condong ke arah tidak melakukannya (bagaimanapun juga itu adalah pekerjaan ekstra). Lihat juga komentar saya di sini .

Jadi, saya tidak berpikir try _mencegah_ orang yang diusulkan dari kesalahan dekorasi (mereka sudah putus asa bahkan dengan if karena alasan di atas); itu try tidak _mendorong_ itu.

(Salah satu cara untuk mendorongnya adalah dengan mengikatnya ke try : Seseorang hanya dapat menggunakan try jika ia juga menghiasi kesalahannya, atau secara eksplisit menyisih.)

Tetapi kembali ke saran Anda: Saya pikir Anda memperkenalkan lebih banyak mesin di sini. Mengubah semantik defer hanya untuk membuatnya bekerja lebih baik untuk try bukanlah sesuatu yang ingin kami pertimbangkan kecuali perubahan defer bermanfaat dalam cara yang lebih umum. Juga, saran Anda mengikat defer bersama-sama dengan try dan dengan demikian membuat kedua mekanisme tersebut kurang ortogonal; sesuatu yang ingin kita hindari.

Tetapi yang lebih penting, saya ragu Anda ingin memaksa semua orang untuk menulis defer agar mereka dapat menggunakan try . Tapi tanpa melakukan itu, kita kembali ke titik awal: orang akan condong ke arah tidak mendekorasi kesalahan.

(Saya suka memiliki handler, dalam hal ini. Ini adalah salah satu proposal kami sebelumnya. Dan jika kita mengadopsi try apa adanya, kita masih dapat bergerak ke arah try dengan handler dengan cara yang kompatibel ke depan - setidaknya jika handlernya opsional. Tapi mari kita lakukan selangkah demi selangkah.)

Tentu, mungkin pendekatan multi-langkah adalah cara yang harus dilakukan. Jika kita menambahkan argumen handler opsional di masa mendatang, perkakas dapat dibuat untuk memperingatkan penulis tentang try yang tidak ditangani dalam semangat yang sama dengan alat errcheck . Apapun, saya menghargai umpan balik Anda!

@alanfo Terima kasih atas umpan balik positif Anda.

Mengenai poin yang Anda kemukakan:

1) Jika satu-satunya masalah dengan try adalah kenyataan bahwa seseorang harus memberi nama pengembalian kesalahan sehingga kami dapat menghias kesalahan melalui defer , saya pikir kami baik-baik saja. Jika penamaan hasil ternyata menjadi masalah nyata, kita bisa mengatasinya. Mekanisme sederhana yang dapat saya pikirkan adalah variabel yang dideklarasikan sebelumnya yang merupakan alias untuk hasil kesalahan (anggap itu sebagai menahan kesalahan yang memicu try terbaru). Mungkin ada ide yang lebih baik. Kami tidak mengusulkan ini karena sudah ada mekanisme dalam bahasa, yaitu untuk memberi nama hasilnya.
2) try dan pengujian: Ini dapat diatasi dan dibuat berfungsi. Lihat dokumen rinci.
3) Ini secara eksplisit dibahas dalam dokumen terperinci.
4) Diakui.

@benhoyt Terima kasih atas umpan balik positif Anda.

Jika argumen utama yang menentang proposal ini adalah fakta bahwa try adalah bawaan, kami berada di posisi yang tepat. Menggunakan built-in hanyalah solusi pragmatis untuk masalah kompatibilitas ke belakang (kebetulan tidak menyebabkan pekerjaan tambahan untuk parser, dan alat dll. - tapi itu hanya manfaat sampingan yang bagus, bukan alasan utama). Ada juga beberapa keuntungan karena harus menulis tanda kurung, hal ini dibahas secara rinci dalam dokumen desain (bagian tentang Properti dari desain yang diusulkan).

Semua yang dikatakan, jika menggunakan built-in adalah showstopper, kita harus mempertimbangkan kata kunci try . Itu tidak akan kompatibel ke belakang meskipun dengan kode yang ada karena kata kunci mungkin bertentangan dengan pengidentifikasi yang ada.

(Untuk melengkapi, ada juga opsi operator seperti ? , yang akan kompatibel ke belakang. Namun, menurut saya, itu bukan pilihan terbaik untuk bahasa seperti Go. Tapi sekali lagi, jika hanya itu yang diperlukan untuk membuat try enak, kita mungkin harus mempertimbangkannya.)

@ugorji Terima kasih atas umpan balik positif Anda.

try dapat diperluas untuk mengambil argumen tambahan. Preferensi kami adalah mengambil hanya fungsi dengan tanda tangan func (error) error . Jika Anda ingin panik, mudah untuk menyediakan fungsi pembantu satu baris:

func doPanic(err error) error { panic(err) }

Lebih baik menjaga desain try tetap sederhana.

@patrick-nyt Apa yang Anda sarankan :

file, err := os.Open("file.go")
try(err)

akan mungkin dengan proposal saat ini.

@dpinela , @ugorji Silakan baca juga dokumen desain tentang must vs try . Lebih baik menyimpan try sesederhana mungkin. must adalah "pola" umum dalam ekspresi inisialisasi, tetapi tidak ada kebutuhan mendesak untuk "memperbaikinya".

@jargv Terima kasih atas saran Anda. Ini adalah ide yang menarik (lihat juga komentar saya di sini tentang hal ini). Untuk meringkas:

• try(x) beroperasi seperti yang diusulkan
• try() mengembalikan *error yang menunjuk ke hasil kesalahan

Ini memang cara lain untuk mendapatkan hasil tanpa harus menamainya.

@cespare Saran oleh @jargv terlihat jauh lebih sederhana bagi saya daripada yang Anda usulkan . Ini memecahkan masalah yang sama dari akses ke kesalahan hasil. Bagaimana menurutmu?

Sesuai https://github.com/golang/go/issues/32437#issuecomment -499320588:

func doPanic(err error) error { panik(err) }

Saya mengantisipasi fungsi ini akan sangat umum. Bisakah ini ditentukan sebelumnya dalam "builtin" (atau di tempat lain dalam paket standar misalnya errors )?

Sayang sekali Anda tidak mengantisipasi obat generik yang cukup kuat untuk diterapkan
coba, saya sebenarnya berharap itu mungkin dilakukan.

Ya, proposal ini bisa menjadi langkah pertama, meskipun saya tidak melihat banyak gunanya
itu sendiri seperti berdiri sekarang.

Memang, masalah ini mungkin terlalu fokus pada alternatif terperinci,
tetapi ini menunjukkan bahwa banyak peserta tidak sepenuhnya senang dengan
dia. Apa yang tampaknya kurang adalah konsensus yang luas tentang proposal ini...

Op vr 7 Juni 2019 01:04 schreef pj [email protected] :

Asper #32437 (komentar)
https://github.com/golang/go/issues/32437#issuecomment-499320588 :

func doPanic(err error) error { panik(err) }

Saya mengantisipasi fungsi ini akan sangat umum. Mungkinkah ini sudah ditentukan sebelumnya?
dalam "bawaan"?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/golang/go/issues/32437?email_source=notifications&email_token=AAARM6OOOLLYO5ZCE6VVL2TPZGJWRA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVX99HJKTDN5WW69
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAARM6K5AOR2DES4QDTNLSTPZGJWRANCNFSM4HTGCZ7Q
.

@pjebs , saya telah menulis fungsi yang setara puluhan kali. Saya biasanya menyebutnya "orDie" atau "check". Ini sangat sederhana, tidak perlu menjadikannya bagian dari perpustakaan standar. Plus orang yang berbeda mungkin ingin masuk atau apa pun sebelum penghentian.

@beoran Mungkin Anda bisa memperluas koneksi antara obat generik dan penanganan kesalahan. Ketika saya memikirkannya, mereka tampak seperti dua hal yang berbeda. Generics bukanlah catch all yang bisa mengatasi semua masalah dengan bahasa. Ini adalah kemampuan untuk menulis satu fungsi yang dapat beroperasi pada beberapa jenis.

Proposal penanganan kesalahan khusus ini mencoba mengurangi boilerplate dengan memperkenalkan fungsi yang telah dideklarasikan sebelumnya try yang mengubah kontrol aliran dalam beberapa keadaan. Obat generik tidak akan pernah mengubah aliran kontrol. Jadi saya benar-benar tidak melihat hubungannya.

Reaksi awal saya terhadap ini adalah karena saya membayangkan bahwa menangani beberapa panggilan rawan kesalahan dalam suatu fungsi akan membuat pegangan kesalahan defer membingungkan. Setelah membaca seluruh proposal, saya membalikkan reaksi saya menjadi ❤️ dan 👍 ketika saya mengetahui bahwa ini masih dapat dicapai dengan kompleksitas yang relatif rendah.

@carlmjohnson Ya itu sederhana tapi...

Saya telah menulis fungsi yang setara puluhan kali.

Keuntungan dari fungsi yang dideklarasikan adalah:

1. Kita bisa satu baris itu
2. Kita tidak perlu mendeklarasikan ulang fungsi err => panic di setiap paket yang kita gunakan, atau mempertahankan lokasi yang sama untuk itu. Karena mungkin umum untuk semua orang di komunitas Go, "paket standar" adalah _ _ lokasi umum untuk itu.

@griesemer Dengan varian penangan kesalahan dari proposal percobaan asli, apakah persyaratan fungsi menyeluruh untuk mengembalikan kesalahan sekarang tidak lagi diperlukan.

Ketika saya pertama kali menanyakannya err => panic, saya ditunjukkan bahwa proposal tersebut mempertimbangkannya tetapi menganggapnya terlalu berbahaya (untuk alasan yang baik). Tetapi jika kita menggunakan try() tanpa penangan kesalahan dalam skenario di mana fungsi menyeluruh tidak mengembalikan kesalahan, membuatnya menjadi kesalahan waktu kompilasi mengurangi kekhawatiran yang dibahas dalam proposal

@pjebs Persyaratan fungsi menyeluruh untuk mengembalikan kesalahan tidak diperlukan dalam desain asli _jika_ penangan kesalahan disediakan. Tapi itu hanya komplikasi lain dari try . Ini _jauh_ lebih baik untuk membuatnya tetap sederhana. Alih-alih, akan lebih jelas untuk memiliki fungsi must terpisah, yang selalu panik karena kesalahan (tetapi sebaliknya seperti try ). Maka jelas apa yang terjadi dalam kode dan kita tidak perlu melihat konteksnya.

Daya tarik utama memiliki must seperti itu adalah dapat digunakan dengan pengujian unit; terutama jika paket testing telah disesuaikan dengan tepat untuk pulih dari kepanikan yang disebabkan oleh must dan melaporkannya sebagai kegagalan pengujian dengan cara yang baik. Tetapi mengapa menambahkan mekanisme bahasa baru ketika kita dapat menyesuaikan paket pengujian untuk juga menerima fungsi pengujian dari bentuk TestXxx(t *testing.T) error ? Jika mereka mengembalikan kesalahan, yang tampaknya cukup alami (mungkin kita seharusnya melakukan ini sejak awal), maka try akan bekerja dengan baik. Tes lokal akan membutuhkan sedikit lebih banyak pekerjaan, tetapi mungkin bisa dilakukan.

Penggunaan lain yang relatif umum untuk must adalah dalam ekspresi inisialisasi global ( must(regexp.Compile... , dll.). Jika akan menjadi "baik untuk dimiliki" tetapi itu tidak selalu menaikkannya ke tingkat yang diperlukan untuk fitur bahasa baru.

@griesemer Mengingat bahwa must samar-samar terkait dengan try , dan mengingat bahwa momentum menuju try diimplementasikan, tidakkah menurut Anda baik untuk mempertimbangkan must pada saat yang sama - meskipun itu hanya "senang untuk dimiliki".

Kemungkinannya adalah jika tidak dibahas dalam babak ini, itu tidak akan diterapkan/dipertimbangkan secara serius, setidaknya selama 3+ tahun (atau mungkin pernah). Tumpang tindih dalam diskusi juga akan lebih baik daripada memulai dari awal dan diskusi daur ulang.

Banyak orang telah menyatakan bahwa must memuji try dengan sangat baik.

@pjebs Tampaknya tidak ada "momentum menuju try diimplementasikan" sekarang... - Dan kami juga baru memposting ini dua hari yang lalu. Juga belum ada yang diputuskan. Mari kita beri waktu ini.

Tidak luput dari kita bahwa must cocok dengan try , tetapi itu tidak sama dengan menjadikannya bagian dari bahasa. Kami baru mulai menjelajahi ruang ini dengan kelompok orang yang lebih luas. Kami benar-benar belum tahu apa yang mungkin muncul untuk mendukung atau menentangnya. Terima kasih.

Setelah menghabiskan berjam-jam membaca semua komentar dan dokumen desain terperinci, saya ingin menambahkan pandangan saya ke proposal ini.

Saya akan melakukan yang terbaik untuk menghormati permintaan @ianlancetaylor untuk tidak hanya menyatakan kembali poin sebelumnya tetapi sebagai gantinya menambahkan komentar baru ke diskusi. Namun saya rasa saya tidak dapat membuat komentar baru tanpa merujuk pada komentar sebelumnya.

Kekhawatiran

Sayangnya kelebihan penangguhan

Preferensi untuk membebani sifat yang jelas dan lugas dari defer sebagai hal yang mengkhawatirkan. Jika saya menulis defer closeFile(f) itu langsung dan jelas bagi saya apa yang terjadi dan mengapa; di akhir fungsi yang akan dipanggil. Dan sementara menggunakan defer untuk panic() dan recover() kurang jelas, saya jarang jika pernah menggunakannya dan hampir tidak pernah melihatnya ketika membaca kode orang lain.

Menipu untuk membebani defer juga menangani kesalahan tidak jelas dan membingungkan. Mengapa kata kunci defer ? Apakah defer tidak berarti _"Lakukan nanti"_ bukannya _"Mungkin nanti?"_

Juga ada kekhawatiran yang disebutkan oleh tim Go tentang kinerja defer . Mengingat hal itu, tampaknya sangat disayangkan bahwa defer sedang dipertimbangkan untuk aliran kode _"hot path"_.

Tidak ada statistik yang memverifikasi kasus penggunaan yang signifikan

Seperti yang disebutkan @prologic , apakah proposal try() ini didasarkan pada sebagian besar kode yang akan menggunakan kasus penggunaan ini, atau apakah ini didasarkan pada upaya untuk menenangkan mereka yang mengeluh tentang penanganan kesalahan Go?

Saya berharap saya tahu bagaimana memberi Anda statistik dari basis kode saya tanpa meninjau secara mendalam setiap file dan membuat catatan; Saya tidak tahu bagaimana @prologic bisa meskipun senang dia melakukannya.

Tetapi secara anekdot saya akan terkejut jika try() menangani 5% dari kasus penggunaan saya dan akan curiga bahwa itu akan menangani kurang dari 1%. Apakah Anda tahu pasti bahwa orang lain memiliki hasil yang sangat berbeda? Sudahkah Anda mengambil bagian dari pustaka standar dan mencoba melihat bagaimana penerapannya?

Karena tanpa statistik yang diketahui bahwa ini sesuai untuk sejumlah besar kode di alam liar, saya harus bertanya apakah perubahan rumit baru ini pada bahasa yang akan mengharuskan semua orang untuk mempelajari konsep-konsep baru benar-benar mengatasi sejumlah kasus penggunaan yang menarik?

Memudahkan pengembang untuk mengabaikan kesalahan

Ini adalah pengulangan total dari apa yang orang lain komentari, tetapi apa yang pada dasarnya memberikan try() analog dalam banyak hal untuk hanya merangkul yang berikut sebagai kode idomatik, dan ini adalah kode yang tidak akan pernah menemukan jalannya ke kode mana pun. -menghormati kapal pengembang:

f, _ := os.Open(filename)

Saya tahu saya bisa lebih baik dalam kode saya sendiri, tetapi saya juga tahu banyak dari kita bergantung pada kebesaran pengembang Go lain yang menerbitkan beberapa paket yang sangat berguna, tetapi dari apa yang saya lihat di _"Kode Orang Lain(tm)"_ praktik terbaik dalam penanganan kesalahan sering diabaikan.

Serius, apakah kami benar-benar ingin mempermudah pengembang untuk mengabaikan kesalahan dan mengizinkan mereka mengotori GitHub dengan paket yang tidak kuat?

Bisa (kebanyakan) sudah mengimplementasikan try() di userland

Kecuali saya salah memahami proposal - yang mungkin saya lakukan - ini adalah try() di Go Playground yang diimplementasikan di userland , meskipun hanya dengan satu (1) nilai pengembalian dan mengembalikan antarmuka alih-alih tipe yang diharapkan:

package main

import (
    "errors"
    "fmt"
    "strings"
)
func main() {
    defer func() {
        r := recover()
        if r != nil && strings.HasPrefix(r.(string),"TRY:") {
            fmt.Printf("Ouch! %s",strings.TrimPrefix(r.(string),"TRY: "))
        }
    }()
    n := try(badjuju()).(int)
    fmt.Printf("Just chillin %dx!",n)   
}
func badjuju() (int,error) {
    return 10, errors.New("this is a really bad error")
}
func try(args ...interface{}) interface{} {
    err,ok := args[1].(error)
    if ok && err != nil {
        panic(fmt.Sprintf("TRY: %s",err.Error()))
    }
    return args[0]
}

Jadi pengguna dapat menambahkan try2() , try3() dan seterusnya tergantung pada berapa banyak nilai pengembalian yang mereka butuhkan untuk dikembalikan.

Tetapi Go hanya memerlukan satu (1) fitur bahasa _ sederhana _ yang universal untuk memungkinkan pengguna yang ingin try() menggulirkan dukungan mereka sendiri, meskipun yang masih memerlukan pernyataan tipe eksplisit. Tambahkan kemampuan _(sepenuhnya kompatibel ke belakang)_ untuk Go func untuk mengembalikan sejumlah variadik nilai pengembalian, misalnya:

func try(args ...interface{}) ...interface{} {
    err,ok := args[1].(error)
    if ok && err != nil {
        panic(fmt.Sprintf("TRY: %s",err.Error()))
    }
    return args[0:len(args)-2]
}

Dan jika Anda membahas obat generik terlebih dahulu maka jenis pernyataan bahkan tidak akan diperlukan _(walaupun saya pikir kasus penggunaan untuk obat generik harus dikurangi dengan menambahkan builtin untuk mengatasi kasus penggunaan generik daripada menambahkan semantik membingungkan dan salad sintaks dari obat generik dari Java dkk.)_

Kurangnya kejelasan

Saat mempelajari kode proposal, saya menemukan bahwa perilakunya tidak jelas dan agak sulit untuk dipikirkan.

Ketika saya melihat try() membungkus ekspresi, apa yang akan terjadi jika kesalahan dikembalikan?

Apakah kesalahan akan diabaikan begitu saja? Atau akankah ia melompat ke defer pertama atau terbaru, dan jika demikian, ia akan secara otomatis menetapkan variabel bernama err di dalam penutupan itu, atau akankah ia meneruskannya sebagai parameter _(I tidak melihat parameter?)_. Dan jika bukan nama kesalahan otomatis, bagaimana saya menamainya? Dan apakah itu berarti saya tidak dapat mendeklarasikan variabel err saya sendiri di fungsi saya, untuk menghindari bentrokan?

Dan apakah itu akan memanggil semua defer ? Dalam urutan terbalik atau urutan biasa?

Atau apakah itu akan kembali dari penutupan dan func tempat kesalahan dikembalikan? _(Sesuatu yang tidak akan pernah saya pertimbangkan jika saya tidak membaca di sini kata-kata yang menyiratkan hal itu.)_

Setelah membaca proposal dan semua komentar sejauh ini saya masih jujur ​​​​tidak tahu jawaban atas pertanyaan di atas. Apakah itu jenis fitur yang ingin kami tambahkan ke bahasa yang pendukungnya diperjuangkan sebagai _"Captain Obvious?"_

Kurang kontrol

Menggunakan defer , tampaknya satu-satunya kontrol yang akan diberikan pengembang adalah bercabang ke _(yang terbaru?)_ defer . Tetapi dalam pengalaman saya dengan metode apa pun di luar func yang sepele biasanya lebih rumit dari itu.

Seringkali saya merasa berguna untuk berbagi aspek penanganan kesalahan dalam func — atau bahkan melintasi package — tetapi kemudian juga memiliki penanganan yang lebih spesifik yang dibagikan di satu atau lebih paket lain.

Misalnya, saya dapat memanggil lima (5) func panggilan yang mengembalikan error() dari dalam func lain; mari kita beri label A() , B() , C() , D() , dan E() . Saya mungkin perlu C() untuk memiliki penanganan kesalahannya sendiri, A() , B() , D() , dan E() untuk membagikan beberapa penanganan kesalahan, dan B() dan E() untuk memiliki penanganan khusus.

Tapi saya tidak percaya akan mungkin untuk melakukan itu dengan proposal ini. Setidaknya tidak mudah.

Namun, ironisnya, Go sudah memiliki fitur bahasa yang memungkinkan tingkat fleksibilitas tinggi yang tidak perlu dibatasi pada sejumlah kecil kasus penggunaan; func s dan penutupan. Jadi pertanyaan retoris saya adalah:

_ "Mengapa kita tidak bisa menambahkan sedikit peningkatan pada bahasa yang ada untuk mengatasi kasus penggunaan ini dan tidak perlu menambahkan fungsi bawaan baru atau menerima semantik yang membingungkan?" _

Ini adalah pertanyaan retoris karena saya berencana untuk mengajukan proposal sebagai alternatif, yang saya pikirkan selama studi proposal ini dan sambil mempertimbangkan semua kekurangannya.

Tapi saya ngelantur, itu akan datang nanti dan komentar ini tentang mengapa proposal saat ini perlu dipertimbangkan kembali.

Kurangnya dukungan yang dinyatakan untuk break

Ini mungkin terasa seperti keluar dari bidang kiri karena kebanyakan orang menggunakan pengembalian awal untuk penanganan kesalahan, tetapi saya telah menemukan bahwa lebih baik menggunakan break untuk penanganan kesalahan membungkus sebagian besar atau semua fungsi sebelum return .

Saya telah menggunakan pendekatan ini untuk sementara dan manfaatnya dalam mengurangi refactoring saja membuatnya lebih disukai daripada awal return , tetapi memiliki beberapa manfaat lain termasuk titik keluar tunggal dan kemampuan untuk mengakhiri bagian dari suatu fungsi lebih awal tetapi masih dapat menjalankan pembersihan _(yang mungkin mengapa saya sangat jarang menggunakan defer , yang menurut saya lebih sulit untuk dijelaskan dalam hal aliran program.)_

Untuk menggunakan break alih-alih pengembalian awal, gunakan loop for range "1" {...} untuk membuat blok agar break keluar dari _(Saya sebenarnya membuat paket bernama only yang hanya berisi konstanta disebut Once dengan nilai "1" ):_

func (me *Config) WriteFile() (err error) {
    for range only.Once {
        var j []byte
        j, err = json.MarshalIndent(me, "", "    ")
        if err != nil {
            err = fmt.Errorf("unable to marshal config; %s", 
                err.Error(),
            )
            break
        }
        err = me.MaybeMakeDir(me.GetDir(), os.ModePerm)
        if err != nil {
            err = fmt.Errorf("unable to make directory'%s'; %s", 
                me.GetDir(), 
                err.Error(),
            )
            break
        }
        err = ioutil.WriteFile(string(me.GetFilepath()), j, os.ModePerm)
        if err != nil {
            err = fmt.Errorf("unable to write to config file '%s'; %s", 
                me.GetFilepath(), 
                err.Error(),
            )
            break
        }
    }
    return err
}

Saya berencana untuk blog tentang pola panjang lebar dalam waktu dekat, dan membahas beberapa alasan mengapa saya menemukan itu bekerja lebih baik daripada pengembalian awal.

Tapi saya ngelantur. Alasan saya membawanya ke sini adalah saya harus Go untuk mengimplementasikan penanganan kesalahan yang mengasumsikan return s awal dan mengabaikan penggunaan break untuk penanganan kesalahan

Pendapat saya err == nil bermasalah

Sebagai penyimpangan lebih lanjut, saya ingin mengemukakan kekhawatiran yang saya rasakan tentang penanganan kesalahan idiomatik di Go. Meskipun saya sangat percaya pada filosofi Go untuk menangani kesalahan ketika terjadi vs. menggunakan penanganan pengecualian, saya merasa penggunaan nil untuk menunjukkan tidak ada kesalahan merupakan masalah karena saya sering menemukan bahwa saya ingin mengembalikan pesan sukses dari rutin — untuk digunakan dalam respons API — dan tidak hanya mengembalikan nilai bukan nol hanya ketika ada kesalahan.

Jadi untuk Go 2 saya sangat ingin melihat Go mempertimbangkan untuk menambahkan tipe bawaan baru status dan tiga fungsi bawaan iserror() , iswarning() , issuccess() . status dapat mengimplementasikan error — memungkinkan banyak kompatibilitas ke belakang dan nilai nil yang diteruskan ke issuccess() akan mengembalikan true — tetapi status akan memiliki status internal tambahan untuk tingkat kesalahan sehingga pengujian untuk tingkat kesalahan akan selalu dilakukan dengan salah satu fungsi bawaan dan idealnya tidak pernah dengan pemeriksaan nil . Itu akan memungkinkan sesuatu seperti pendekatan berikut sebagai gantinya:

func (me *Config) WriteFile() (sts status) {
    for range only.Once {
        var j []byte
        j, sts = json.MarshalIndent(me, "", "    ")
        if iserror(sts) {
            sts.AddMessage("unable to marshal config")
            break
        }
        sts = me.MaybeMakeDir(me.GetDir(), os.ModePerm)
        if iserror(sts) {
            sts.AddMessage("unable to make directory'%s'", me.GetDir())
            break
        }
        sts = ioutil.WriteFile(string(me.GetFilepath()), j, os.ModePerm)
        if iserror(sts) {
            sts.AddMessage("unable to write to config file '%s'", 
                me.GetFilepath(), 
            )
            break
        }
        sts = fmt.Status("config file written")
    }
    return sts
}

Saya sudah menggunakan pendekatan userland di tingkat pra-beta saat ini paket penggunaan internal yang mirip dengan di atas untuk penanganan kesalahan. Terus terang saya menghabiskan lebih sedikit waktu untuk memikirkan bagaimana menyusun kode saat menggunakan pendekatan ini daripada ketika saya mencoba mengikuti penanganan kesalahan Go idiomatis.

Jika menurut Anda ada peluang untuk mengembangkan kode Go idiomatis ke pendekatan ini, harap pertimbangkan saat menerapkan penanganan kesalahan, termasuk saat mempertimbangkan proposal try() ini.

_"Tidak untuk semua orang"_ pembenaran

Salah satu tanggapan utama dari tim Go adalah _"Sekali lagi, proposal ini tidak berusaha menyelesaikan semua situasi penanganan kesalahan."_
Dan itu mungkin masalah yang paling meresahkan, dari perspektif tata kelola.

Apakah perubahan baru yang rumit pada bahasa yang akan mengharuskan setiap orang untuk mempelajari konsep-konsep baru ini benar-benar mengatasi sejumlah kasus penggunaan yang menarik?

Dan bukankah itu pembenaran yang sama bahwa anggota tim inti telah menolak banyak permintaan fitur dari komunitas? Berikut ini adalah kutipan langsung dari komentar yang dibuat oleh anggota tim Go dalam tanggapan tipikal atas permintaan fitur yang diajukan sekitar 2 tahun yang lalu _(Saya tidak menyebutkan nama orang atau permintaan fitur tertentu karena diskusi ini seharusnya tidak dapat dilakukan orangnya tapi tentang bahasanya):_

_"Fitur bahasa baru memerlukan kasus penggunaan yang menarik. Semua fitur bahasa berguna, atau tidak ada yang akan mengusulkannya; pertanyaannya adalah: apakah fitur tersebut cukup berguna untuk membenarkan kerumitan bahasa dan mengharuskan semua orang mempelajari konsep baru? Apa kegunaan yang menarik itu? kasus di sini? Bagaimana orang akan menggunakan ini? Misalnya, apakah orang berharap dapat ... dan jika demikian, bagaimana mereka akan melakukannya? Apakah proposal ini lebih dari sekadar memungkinkan Anda...?"_
— Anggota tim inti Go

Terus terang ketika saya melihat tanggapan itu, saya merasakan salah satu dari dua perasaan:

1. Kemarahan jika itu adalah fitur yang saya setujui, atau
2. Kegembiraan jika itu adalah fitur yang saya tidak setuju.

Tetapi dalam kedua kasus, perasaan saya tidak relevan; Saya mengerti dan setuju bahwa sebagian dari alasan Go adalah bahasa yang dipilih oleh banyak dari kita untuk berkembang adalah karena penjagaan kemurnian bahasa yang cemburu.

Dan itulah mengapa proposal ini sangat mengganggu saya, karena tim inti Go tampaknya menggali proposal ini ke tingkat yang sama dengan seseorang yang secara dogmatis menginginkan fitur esoteris yang tidak mungkin ditoleransi oleh komunitas Go.

_(Dan saya sangat berharap tim tidak akan menembak utusan dan menganggap ini sebagai kritik membangun dari seseorang yang ingin melihat Go terus menjadi yang terbaik untuk kita semua karena saya harus dianggap "Persona non grata" oleh tim inti.)_

Jika memerlukan serangkaian kasus penggunaan dunia nyata yang menarik adalah standar untuk semua proposal fitur yang dibuat komunitas, bukankah seharusnya itu juga menjadi standar yang sama untuk _ semua _ proposal fitur?

Bersarang dari coba()

Ini juga dicakup oleh beberapa, tetapi saya ingin menggambar perbandingan antara try() dan permintaan lanjutan untuk operator ternary. Mengutip dari komentar anggota tim Go lainnya sekitar 18 bulan yang lalu:

_"ketika "memprogram dalam skala besar" (basis kode besar dengan tim besar dalam jangka waktu yang lama), kode dibaca JAUH lebih sering daripada yang tertulis, jadi kami mengoptimalkan keterbacaan, bukan penulisan."_

Salah satu alasan yang dinyatakan _primary_ untuk tidak menambahkan operator ternary adalah karena operator tersebut sulit dibaca dan/atau mudah salah dibaca saat bersarang. Namun hal yang sama dapat terjadi pada pernyataan try() bersarang seperti try(try(try(to()).parse().this)).easily()) .

Alasan tambahan untuk membantah operator ternary adalah bahwa mereka adalah _"ekspresi"_ dengan argumen bahwa ekspresi bersarang dapat menambah kompleksitas. Tetapi bukankah try() membuat ekspresi yang dapat disarang juga?

Sekarang seseorang di sini berkata _"Saya pikir contoh seperti [bersarang try() s] tidak realistis"_ dan pernyataan itu tidak ditentang.

Tetapi jika orang menerima sebagai dalil bahwa pengembang tidak akan bersarang try() lalu mengapa penghormatan yang sama tidak diberikan kepada operator ternary ketika orang mengatakan _"Saya pikir operator ternary yang sangat bersarang tidak realistis?"_

Intinya untuk poin ini, saya pikir jika argumen terhadap operator ternary benar-benar valid, maka mereka juga harus dianggap sebagai argumen yang valid terhadap proposal try() ini.

Singkatnya

Pada saat penulisan ini 58% suara turun menjadi 42% suara naik. Saya pikir ini saja sudah cukup untuk menunjukkan bahwa ini cukup memecah belah proposal sehingga sudah waktunya untuk kembali ke papan gambar tentang masalah ini.

fwiw

PS Untuk membuatnya lebih lidah-di-pipi, saya pikir kita harus mengikuti kebijaksanaan Yoda yang diparafrasekan:

_"Tidak ada try() . Hanya do() ."_

@ianlancetaylor

@beoran Mungkin Anda bisa memperluas koneksi antara obat generik dan penanganan kesalahan.

Tidak berbicara untuk @beoran tetapi dalam komentar saya dari beberapa menit yang lalu Anda akan melihat bahwa jika kami memiliki obat generik _(plus parameter pengembalian variadic)_ maka kami dapat membangun try() kami sendiri.

Namun — dan saya akan mengulangi apa yang saya katakan di atas tentang obat generik di sini di mana akan lebih mudah untuk melihat:

_" Saya pikir kasus penggunaan untuk obat generik harus dikurangi dengan menambahkan bawaan untuk mengatasi kasus penggunaan generik daripada menambahkan semantik membingungkan dan salad sintaks generik dari Java et. al.)"_

@ianlancetaylor

Ketika mencoba merumuskan jawaban untuk pertanyaan Anda, saya mencoba menerapkan fungsi try di Go apa adanya, dan saya senang, sebenarnya sudah mungkin untuk meniru sesuatu yang sangat mirip:

func try(v interface{}, err error) interface{} {
   if err != nil { 
     panic(err)
   }
   return v
}

Lihat di sini cara menggunakannya: https://play.golang.org/p/Kq9Q0hZHlXL

Kelemahan dari pendekatan ini adalah:

1. Penyelamatan yang ditangguhkan diperlukan, tetapi dengan try seperti dalam proposal ini, penangan yang ditangguhkan juga diperlukan jika kita ingin melakukan penanganan kesalahan yang tepat. Jadi saya merasa ini bukan kerugian yang serius. Bahkan bisa lebih baik jika Go memiliki semacam super(arg1, ..., argn) bawaan yang menyebabkan penelepon, satu tingkat di atas tumpukan panggilan, untuk kembali dengan argumen yang diberikan arg1,...argn, semacam pengembalian super jika Anda mau.
2. try yang saya terapkan ini hanya dapat bekerja dengan fungsi yang mengembalikan satu hasil dan kesalahan.
3. Anda harus mengetikkan hasil antarmuka kosong yang dikembalikan.

Obat generik yang cukup kuat dapat menyelesaikan masalah 2 dan 3, hanya menyisakan 1, yang dapat diselesaikan dengan menambahkan super() . Dengan dua fitur tersebut, kita bisa mendapatkan sesuatu seperti:

func (T ... interface{})try(T, err error) super {
   if err != nil { 
      super(err)
   }
  super(T...)
}

Dan kemudian penyelamatan yang ditangguhkan tidak akan diperlukan lagi. Manfaat ini akan tersedia bahkan jika tidak ada obat generik yang ditambahkan ke Go.

Sebenarnya, ide super() builtin ini sangat kuat dan menarik sehingga saya mungkin memposting proposal untuk itu secara terpisah.

@beoran Senang melihat kami sampai pada kendala yang sama secara independen terkait penerapan try() di userland, kecuali untuk bagian super yang tidak saya sertakan karena saya ingin membicarakan sesuatu yang serupa dalam proposal alternatif. :-)

Saya menyukai proposalnya tetapi fakta bahwa Anda harus secara eksplisit menentukan bahwa defer try(...) dan go try(...) tidak diizinkan membuat saya berpikir ada sesuatu yang tidak beres.... Orthogonalitas adalah panduan desain yang baik. Pada bacaan lebih lanjut dan melihat hal-hal seperti
x = try(foo(...)) y = try(bar(...))
Saya ingin tahu apakah mungkin try perlu menjadi konteks ! Mempertimbangkan:
try ( x = foo(...) y = bar(...) )
Di sini foo() dan bar() mengembalikan dua nilai, yang kedua adalah error . Coba semantik hanya penting untuk panggilan dalam blok try di mana nilai kesalahan yang dikembalikan dihilangkan (tidak ada penerima) sebagai lawan diabaikan (penerima adalah _ ). Anda bahkan dapat menangani beberapa kesalahan di antara panggilan foo dan bar .

Ringkasan:
a) masalah pelarangan try untuk go dan defer menghilang berdasarkan sintaks.
b) penanganan kesalahan beberapa fungsi dapat difaktorkan.
c) sifat ajaibnya lebih baik diekspresikan sebagai sintaksis khusus daripada sebagai pemanggilan fungsi.

Jika try adalah sebuah konteks maka kami baru saja membuat blok try/catch yang secara khusus kami coba hindari (dan untuk alasan yang bagus)

Tidak ada tangkapan. Kode yang sama persis akan dihasilkan seperti saat proposal saat ini memiliki
x = try(foo(...)) y = try(bar(...))
Ini hanya sintaks yang berbeda, bukan semantik.
````

Saya kira saya telah membuat beberapa asumsi tentang hal itu yang seharusnya tidak saya lakukan, meskipun masih ada beberapa kekurangannya.

Bagaimana jika foo atau bar tidak mengembalikan kesalahan, dapatkah mereka ditempatkan dalam konteks try juga? Jika tidak, sepertinya akan agak buruk untuk beralih antara fungsi error dan non-error, dan jika bisa, maka kita kembali ke masalah blok try dalam bahasa yang lebih lama.

Hal kedua adalah bahwa biasanya sintaks keyword ( ... ) berarti Anda mengawali kata kunci pada setiap baris. Jadi untuk import, var, const, dll: setiap baris dimulai dengan kata kunci. Mengecualikan aturan itu sepertinya bukan keputusan yang baik

Alih-alih menggunakan fungsi, apakah akan lebih idiomatis menggunakan pengenal khusus?

Kami sudah memiliki pengidentifikasi kosong _ yang mengabaikan nilai.
Kita dapat memiliki sesuatu seperti # yang hanya dapat digunakan dalam fungsi yang memiliki nilai kesalahan tipe yang dikembalikan terakhir.

func foo() (error) {
    f, # := os.Open()
    defer f.Close()
    _, # = f.WriteString("foo")
    return nil
}

ketika kesalahan ditetapkan ke # fungsi segera kembali dengan kesalahan yang diterima. Adapun variabel lain nilainya adalah:

• jika mereka tidak bernama nilai nol
• nilai yang diberikan ke variabel bernama sebaliknya

@deanveloper , try blok semantik hanya penting untuk fungsi yang mengembalikan nilai kesalahan dan di mana nilai kesalahan tidak ditetapkan. Jadi contoh terakhir dari proposal ini juga dapat ditulis sebagai
try(x = foo(...)) try(y = bar(...))
menempatkan kedua pernyataan dalam blok yang sama mirip dengan apa yang kita lakukan untuk pernyataan import , const dan var berulang.

Sekarang jika sudah, misalnya
try( x = foo(...)) go zee(...) defer fum() y = bar(...) )
Ini setara dengan menulis
try(x = foo(...)) go zee(...) defer fum() try(y = bar(...))
Memfaktorkan semua itu dalam satu blok percobaan membuatnya kurang sibuk.

Mempertimbangkan
try(x = foo())
Jika foo() tidak mengembalikan nilai kesalahan, ini setara dengan
x = foo()

Mempertimbangkan
try(f, _ := os.open(filename))
Karena nilai kesalahan yang dikembalikan diabaikan, ini setara dengan hanya
f, _ := os.open(filename)

Mempertimbangkan
try(f, err := os.open(filename))
Karena nilai kesalahan yang dikembalikan tidak diabaikan, ini setara dengan
f, err := os.open(filename) if err != nil { return ..., err }
Seperti yang saat ini ditentukan dalam proposal.

Dan itu juga mendeklarasikan percobaan bersarang dengan baik!

Berikut ini tautan ke proposal alternatif yang saya sebutkan di atas:

• https://github.com/golang/go/issues/32473

Itu panggilan untuk menambahkan dua (2) fitur bahasa tujuan kecil tapi umum untuk mengatasi kasus penggunaan yang sama seperti try()

1. Kemampuan untuk memanggil func /closure dalam pernyataan tugas.
2. Kemampuan untuk break , continue atau return lebih dari satu level.

Dengan dua fitur ini, mereka tidak akan _"ajaib"_ dan saya yakin penggunaannya akan menghasilkan kode Go yang lebih mudah dipahami dan lebih sesuai dengan kode Go idiomatis yang kita semua kenal.

Saya sudah membaca proposalnya dan sangat suka ke mana coba.

Mengingat seberapa lazimnya percobaan, saya bertanya-tanya apakah menjadikannya perilaku yang lebih default akan membuatnya lebih mudah untuk ditangani.

Pertimbangkan peta. Ini berlaku:

v := m[key]

seperti ini:

v, ok := m[key]

Bagaimana jika kita menangani kesalahan persis seperti yang disarankan oleh try, tetapi hapus file bawaan. Jadi jika kita mulai dengan:

v, err := fn()

Alih-alih menulis:

v := try(fn())

Sebagai gantinya, kita bisa menulis:

v := fn()

Ketika nilai err tidak ditangkap, itu akan ditangani persis seperti percobaan. Perlu sedikit membiasakan diri, tetapi rasanya sangat mirip dengan v, ok := m[key] dan v, ok := x.(string) . Pada dasarnya, setiap kesalahan yang tidak tertangani menyebabkan fungsi kembali dan nilai err ditetapkan.

Untuk kembali ke kesimpulan dokumen desain dan persyaratan implementasi:

• Sintaks bahasa dipertahankan dan tidak ada kata kunci baru yang diperkenalkan
• Ini terus menjadi gula sintaksis seperti try dan mudah-mudahan mudah untuk dijelaskan.
• Tidak memerlukan sintaks baru
• Ini harus benar-benar kompatibel ke belakang.

Saya membayangkan ini akan memiliki persyaratan implementasi yang hampir sama dengan try karena perbedaan utamanya adalah daripada builtin yang memicu gula sintaksis, sekarang tidak adanya bidang err.

Jadi menggunakan contoh CopyFile dari proposal bersama dengan defer fmt.HandleErrorf(&err, "copy %s %s", src, dst) , kita mendapatkan:

func CopyFile(src, dst string) (err error) {
        defer fmt.HandleErrorf(&err, "copy %s %s", src, dst)

        r := os.Open(src)
        defer r.Close()

        w := os.Create(dst)
        defer func() {
                err := w.Close()
                if err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        io.Copy(w, r)
        w.Close()
        return nil
}

@savaki Saya suka ini dan berpikir tentang apa yang diperlukan untuk membuat Go membalik penanganan kesalahan dengan selalu menangani kesalahan secara default dan membiarkan programmer menentukan kapan tidak melakukannya (dengan menangkap kesalahan ke dalam variabel) tetapi sama sekali tidak ada pengenal akan membuat kode sulit untuk diikuti karena orang tidak akan dapat melihat semua poin kembali. Mungkin konvensi untuk memberi nama fungsi yang dapat mengembalikan kesalahan secara berbeda dapat berfungsi (seperti kapitalisasi pengidentifikasi publik). Mungkin jika suatu fungsi mengembalikan kesalahan, itu harus selalu diakhiri dengan, katakanlah ? . Kemudian Go selalu dapat menangani kesalahan secara implisit dan secara otomatis mengembalikannya ke fungsi panggilan seperti try. Ini membuatnya sangat mirip dengan beberapa proposal yang menyarankan untuk menggunakan pengenal ? daripada mencoba tetapi perbedaan penting adalah bahwa di sini ? akan menjadi bagian dari nama fungsi dan bukan pengenal tambahan. Sebenarnya fungsi yang mengembalikan error sebagai nilai pengembalian terakhir bahkan tidak akan dikompilasi jika tidak diakhiri ? . Tentu saja ? bersifat arbitrer dan dapat diganti dengan apa pun yang membuat maksud lebih eksplisit. operation?() akan setara dengan membungkus try(someFunc()) tetapi ? akan menjadi bagian dari nama fungsi dan satu-satunya tujuan adalah untuk menunjukkan bahwa fungsi dapat mengembalikan kesalahan seperti kapitalisasi huruf pertama variabel.

Ini secara dangkal akhirnya menjadi sangat mirip dengan proposal lain yang meminta untuk mengganti try dengan ? tetapi perbedaan kritis adalah membuat penanganan kesalahan implisit (otomatis) dan malah membuat kesalahan pengabaian (atau pembungkusan) eksplisit yang jenis praktik terbaik pula. Masalah yang paling jelas dengan ini tentu saja adalah tidak kompatibel ke belakang dan saya yakin masih banyak lagi.

Yang mengatakan, saya akan sangat tertarik untuk melihat bagaimana Go dapat membuat kesalahan menangani kasus default/implisit dengan mengotomatiskannya dan membiarkan programmer menulis sedikit kode tambahan untuk mengabaikan/mengganti penanganannya. Tantangannya menurut saya adalah bagaimana membuat semua titik balik menjadi jelas dalam kasus ini karena tanpanya kesalahan akan menjadi lebih seperti pengecualian dalam arti bahwa mereka bisa datang dari mana saja karena aliran program tidak akan membuatnya jelas. Bisa dikatakan membuat kesalahan implisit dengan indikator visual sama dengan mengimplementasikan try dan membuat errcheck kegagalan kompilator.

bisakah kita melakukan sesuatu seperti pengecualian c++ dengan dekorator untuk fungsi lama?

func some_old_test() (int, error){
    return 0, errors.New("err1")
}
func some_new_test() (int){
        if true {
             return 1
        }
    throw errors.New("err2")
}
func throw_res(int, e error) int {
    if e != nil {
        throw e
    }
    return int
}
func main() {
    fmt.Println("Hello, playground")
    try{
        i := throw_res(some_old_test())
        fmt.Println("i=", i + some_new_test())
    } catch(err io.Error) {
        return err
    } catch(err error) {
        fmt.Println("unknown err", err)
    }
}

@owais Saya berpikir semantiknya akan persis sama dengan try jadi setidaknya Anda perlu mendeklarasikan tipe err. Jadi jika kita mulai dengan:

func foo() error {
  _, err := fn() 
  if err != nil {
    return err
  }

  return nil
} 

Jika saya memahami proposal percobaan, cukup lakukan ini:

func foo() error {
  _  := fn() 
  return nil
} 

tidak akan dikompilasi. Satu keuntungan yang bagus adalah memberikan kompilasi kesempatan untuk memberi tahu pengguna apa yang hilang. Sesuatu yang menyatakan bahwa menggunakan penanganan kesalahan implisit memerlukan jenis pengembalian kesalahan untuk dinamai, err.

Ini kemudian, akan bekerja:

func foo() (err error) {
  _  := fn() 
  return nil
} 

mengapa tidak menangani kasus kesalahan yang tidak ditetapkan ke variabel saja.

• hapus kebutuhan untuk pengembalian bernama, kompiler dapat melakukan ini semua sendiri.
• memungkinkan untuk menambahkan konteks.
• menangani kasus penggunaan umum.
• kompatibel ke belakang
• tidak berinteraksi secara aneh dengan penundaan, loop, atau sakelar.

pengembalian implisit untuk kasus if err != nil, compiler dapat menghasilkan nama variabel lokal untuk pengembalian jika perlu tidak dapat diakses oleh programmer.
secara pribadi saya tidak suka kasus khusus ini dari sudut pandang keterbacaan kode

f := os.Open("foo.txt")

lebih suka pengembalian eksplisit, mengikuti kode lebih banyak dibaca daripada mantra tertulis

f := os.Open("foo.txt") else return

menariknya kami dapat menerima kedua formulir tersebut, dan telah gofmt secara otomatis menambahkan pengembalian else.

menambahkan konteks, juga penamaan lokal variabel. return menjadi eksplisit karena kita ingin menambahkan konteks.

f := os.Open("foo.txt") else err {
  return errors.Wrap(err, "some context")
}

menambahkan konteks dengan beberapa nilai pengembalian

f := os.Open("foo.txt") else err {
  return i, j, errors.Wrap(err, "some context")
}

fungsi bersarang mengharuskan fungsi luar menangani semua hasil dalam urutan yang sama
dikurangi kesalahan terakhir.

bits := ioutil.ReadAll(os.Open("foo")) else err {
  // either error ends up here.
  return i, j, errors.Wrap(err, "some context")
}

kompiler menolak kompilasi karena nilai pengembalian kesalahan yang hilang dalam fungsi

func foo(s string) int {
   i := strconv.Atoi(s) // cannot implicitly return error due to missing error return value for foo.
   return i * 2
}

dengan senang hati dikompilasi karena kesalahan diabaikan secara eksplisit.

func foo(s string) int {
   i, _ := strconv.Atoi(s)
   return i * 2
} 

kompiler senang. itu mengabaikan kesalahan seperti yang terjadi saat ini karena tidak ada penetapan atau akhiran yang terjadi.

func foo() error {
  return errors.New("whoops")
}

func bar() {
  foo()
}

dalam satu lingkaran Anda dapat menggunakan lanjutkan.

for _, s := range []string{"1","2","3","4","5","6"} {
  i := strconv.Atoi(s) else continue
}

edit: ganti ; dengan else

@savaki Saya pikir saya mengerti komentar asli Anda dan saya suka ide Go menangani kesalahan secara default, tetapi saya pikir itu tidak layak tanpa menambahkan beberapa perubahan sintaks tambahan dan setelah kami melakukannya, itu menjadi sangat mirip dengan proposal saat ini.

Kelemahan terbesar dari apa yang Anda usulkan adalah ia tidak memaparkan semua titik dari mana suatu fungsi dapat kembali tidak seperti if err != nil {return err} saat ini atau fungsi coba yang diperkenalkan dalam proposal ini. Meskipun itu akan berfungsi dengan cara yang persis sama di bawah tenda, secara visual kodenya akan terlihat sangat berbeda. Saat membaca kode, tidak akan ada cara untuk mengetahui panggilan fungsi mana yang mungkin menghasilkan kesalahan. Itu akan menjadi pengalaman yang lebih buruk daripada pengecualian IMO.

Mungkin penanganan kesalahan dapat dibuat implisit jika kompiler memaksakan beberapa konvensi semantik pada fungsi yang dapat mengembalikan kesalahan. Seperti mereka harus dimulai atau diakhiri dengan frasa atau karakter tertentu. Itu akan membuat semua poin pengembalian sangat jelas dan saya pikir itu akan lebih baik daripada penanganan kesalahan manual tetapi tidak yakin seberapa jauh lebih baik mengingat sudah ada pemeriksaan serat yang berteriak memuat ketika mereka melihat kesalahan diabaikan. Akan sangat menarik untuk melihat apakah kompiler dapat memaksa fungsi diberi nama dengan cara tertentu tergantung pada apakah mereka dapat mengembalikan kemungkinan kesalahan.

Kelemahan utama dari pendekatan ini adalah bahwa parameter hasil kesalahan perlu diberi nama, mungkin mengarah ke API yang kurang cantik (tetapi lihat FAQ tentang hal ini). Kami percaya bahwa kami akan terbiasa setelah gaya ini terbentuk dengan sendirinya.

Tidak yakin apakah hal seperti ini telah disarankan sebelumnya, tidak dapat menemukannya di sini atau di proposal. Sudahkah Anda mempertimbangkan fungsi bawaan lain yang mengembalikan pointer ke nilai pengembalian kesalahan fungsi saat ini?
misalnya:

func example() error {
        var err *error = funcerror() // always return a non-nil pointer
        fmt.Print(*err) // always nil if the return parameters are not named and not in a defer

        defer func() {
                err := funcerror()
                fmt.Print(*err) // "x"
        }

        return errors.New("x")
}

func exampleNamed() (err error) {
        funcErr := funcerror()
        fmt.Print(*funcErr) // "nil"

        err = errors.New("x")
        fmt.Print(*funcErr) // "x", named return parameter is reflected even before return is called

        *funcErr = errors.New("y")
        fmt.Print(err) // "y", unfortunate side effect?

        defer func() {
                funcErr := funcerror()
                fmt.Print(*funcErr) // "z"
                fmt.Print(err) // "z"
        }

        return errors.New("z")
}

penggunaan dengan coba:

func CopyFile(src, dst string) (error) {
        defer func() {
                err := funcerror()
                if *err != nil {
                        *err = fmt.Errorf("copy %s %s: %v", src, dst, err)
                }
        }()
        // one liner alternative
        // defer fmt.HandleErrorf(funcerror(), "copy %s %s", src, dst)

        r := try(os.Open(src))
        defer r.Close()

        w := try(os.Create(dst))
        defer func() {
                w.Close()
                err := funcerror()
                if *err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        try(io.Copy(w, r))
        try(w.Close())
        return nil
}

Atau funcerror (namanya sedang dalam proses :D ) dapat mengembalikan nil jika tidak dipanggil di dalam penangguhan.

Alternatif lain adalah funcerror mengembalikan antarmuka "Errorer" untuk membuatnya hanya-baca:

type interface Errorer() {
        Error() error
}

@savaki Saya benar-benar menyukai proposal Anda untuk menghilangkan try() dan membiarkannya lebih seperti menguji peta atau pernyataan tipe. Itu terasa jauh lebih _"Go-like."_

Namun, masih ada satu masalah mencolok yang saya lihat, dan proposal Anda menganggap bahwa semua kesalahan menggunakan pendekatan ini akan memicu return dan meninggalkan fungsi. Apa yang tidak dipikirkannya adalah mengeluarkan break dari for saat ini atau continue untuk for saat ini.

return awal adalah palu godam ketika berkali-kali pisau bedah adalah pilihan yang lebih baik.

Jadi saya menegaskan break dan continue harus diizinkan menjadi strategi penanganan kesalahan yang valid dan saat ini proposal Anda hanya menganggap return sedangkan try() menganggap itu atau memanggil kesalahan handler itu sendiri hanya dapat return , bukan break atau continue .

Sepertinya savaki dan saya memiliki ide yang sama, saya baru saja menambahkan semantik blok untuk menangani kesalahan jika diinginkan. Misalnya menambahkan comtext, untuk loop di mana Anda ingin korsleting dll

@mikeschinkel lihat ekstensi saya, dia dan saya memiliki ide yang sama, saya baru saja memperpanjangnya dengan pernyataan blok opsional

@james-lawrence

@mikesckinkel lihat ekstensi saya, dia dan saya memiliki ide yang sama, saya baru saja memperpanjangnya dengan pernyataan blok opsional

Mengambil contoh Anda:

f := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

Yang dibandingkan dengan apa yang kita lakukan hari ini:

f,err := os.Open("foo.txt"); 
if err != nil {
  return errors.Wrap(err, "some context")
}

Pasti lebih disukai daripada saya. Kecuali itu memiliki beberapa masalah:

1. err tampaknya _"secara ajaib"_ dideklarasikan. Sihir harus diminimalkan, bukan? Jadi mari kita nyatakan:

f, err := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

1. Tapi itu masih tidak berhasil karena Go tidak menafsirkan nilai nil sebagai false atau nilai pointer sebagai true , jadi itu harus:

f, err := os.Open("foo.txt"); err != nil {
  return errors.Wrap(err, "some context")
}

Dan apa yang berhasil, itu mulai terasa seperti banyak pekerjaan dan banyak sintaks dalam satu baris, jadi dan saya mungkin terus melakukan cara lama untuk kejelasan.

Tetapi bagaimana jika Go menambahkan dua (2) bawaan; iserror() dan error() ? Kemudian kita bisa melakukan ini, yang tidak terasa buruk bagi saya:

f := os.Open("foo.txt"); iserror() {
  return errors.Wrap(error(), "some context")
}

Atau lebih baik _(sesuatu seperti):_

f := os.Open("foo.txt"); iserror() {
  return error().Extend("some context")
}

Apa yang Anda, dan orang lain pikirkan?

Sebagai tambahan, periksa ejaan nama pengguna saya. Saya tidak akan diberitahu tentang penyebutan Anda jika saya tidak memperhatikan ...

@mikeschinkel maaf tentang nama yang saya gunakan di ponsel saya dan github tidak menyarankan secara otomatis.

err tampaknya "secara ajaib" dinyatakan. Sihir harus diminimalkan, bukan? Jadi mari kita nyatakan:

meh, seluruh ide memasukkan pengembalian secara otomatis adalah ajaib. ini bukanlah hal yang paling ajaib yang terjadi di seluruh proposal ini. Ditambah lagi, saya berpendapat bahwa err dinyatakan; tepat di akhir di dalam konteks blok cakupan yang mencegahnya mencemari ruang lingkup induk sambil tetap mempertahankan semua hal baik yang kita dapatkan secara normal dengan menggunakan pernyataan if.

Saya biasanya cukup senang dengan penanganan kesalahan go dengan penambahan yang akan datang ke paket kesalahan. Saya tidak melihat apa pun dalam proposal ini sebagai hal yang sangat membantu. Saya hanya mencoba menawarkan kecocokan paling alami untuk golang jika kita benar-benar ingin melakukannya.

_"seluruh gagasan untuk memasukkan pengembalian secara otomatis adalah ajaib."_

Anda tidak akan mendapatkan argumen dari saya di sana.

_"ini bukanlah hal yang paling ajaib yang terjadi di seluruh proposal ini."_

Kurasa aku mencoba berargumen bahwa _"semua sihir itu bermasalah."_

_"Ditambah lagi, saya berpendapat bahwa err dinyatakan; tepat di akhir di dalam konteks blok cakupan..."_

Jadi jika saya ingin menyebutnya err2 ini akan berhasil juga?

f := os.Open("foo.txt"); err2 {
  return errors.Wrap(err, "some context")
}

Jadi saya berasumsi Anda juga mengusulkan penanganan kasus khusus dari err / err2 setelah titik koma, yaitu bahwa itu akan dianggap sebagai nil atau bukan nil bukannya bool seperti saat memeriksa peta?

if _,ok := m[a]; !ok {
   print("there is no 'a' in 'm'")
}

Saya biasanya cukup senang dengan penanganan kesalahan go dengan penambahan yang akan datang ke paket kesalahan.

Saya juga senang dengan penanganan kesalahan, bila digabungkan dengan break dan continue _(tetapi tidak return .)_

Karena itu, saya melihat proposal try() ini lebih berbahaya daripada membantu, dan lebih suka tidak melihat apa pun selain implementasi ini sebagaimana diusulkan. #jmtcw.

@beoran @mikeschinkel Sebelumnya saya menyarankan bahwa kita tidak bisa mengimplementasikan versi try ini menggunakan obat generik, karena mengubah aliran kontrol. Jika saya membaca dengan benar, Anda berdua menyarankan agar kami menggunakan obat generik untuk mengimplementasikan try dengan memanggilnya panic . Tetapi versi try ini secara eksplisit tidak panic . Jadi kami tidak dapat menggunakan obat generik untuk mengimplementasikan versi try ini.

Ya, kami dapat menggunakan obat generik (versi obat generik secara signifikan lebih kuat daripada yang ada di draf desain di https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md) untuk menulis fungsi yang panik pada kesalahan. Tapi panik pada kesalahan bukanlah jenis penanganan kesalahan yang ditulis oleh programmer Go hari ini, dan sepertinya itu bukan ide yang baik bagi saya.

@mikeschinkel penanganan khusus adalah blok dijalankan hanya ketika ada kesalahan.
```
f := os.Open('foo'); err { return err } // err akan selalu nol di sini.

@ianlancetaylor

_"Ya, kita bisa menggunakan obat generik ... Tapi panik pada kesalahan bukanlah jenis penanganan kesalahan yang ditulis oleh programmer Go hari ini, dan sepertinya itu bukan ide yang bagus untuk saya."_

Saya sebenarnya sangat setuju dengan Anda tentang hal ini sehingga tampaknya Anda mungkin salah mengartikan maksud dari komentar saya. Saya sama sekali tidak menyarankan bahwa tim Go akan menerapkan penanganan kesalahan yang menggunakan panic() — tentu saja tidak.

Sebaliknya saya mencoba untuk benar-benar mengikuti petunjuk Anda dari banyak komentar Anda sebelumnya tentang masalah lain dan menyarankan agar kami menghindari membuat perubahan apa pun pada Go yang tidak mutlak diperlukan karena hal itu mungkin dilakukan di userland . Jadi _if_ obat generik ditangani _then_ orang yang ingin try() sebenarnya dapat mengimplementasikannya sendiri, meskipun dengan memanfaatkan panic() . Dan itu akan menjadi satu fitur lebih sedikit yang perlu ditambahkan dan didokumentasikan oleh tim untuk Go.

Apa yang tidak saya lakukan — dan mungkin itu tidak jelas — adalah menganjurkan agar orang benar-benar menggunakan panic() untuk mengimplementasikan try() , hanya saja mereka dapat melakukannya jika mereka benar-benar menginginkannya, dan mereka memiliki fitur obat generik.

Apakah itu memperjelas?

Bagi saya memanggil panic , bagaimanapun itu dilakukan, sangat berbeda dari proposal ini untuk try . Jadi sementara saya pikir saya mengerti apa yang Anda katakan, saya tidak setuju bahwa mereka setara. Bahkan jika kami memiliki obat generik yang cukup kuat untuk mengimplementasikan versi try yang membuat panik, saya pikir masih ada keinginan yang masuk akal untuk versi try yang disajikan dalam proposal ini.

@ianlancetaylor Diakui. Sekali lagi, saya mencari alasan bahwa try() tidak perlu ditambahkan daripada mencari cara untuk menambahkannya. Seperti yang saya katakan di atas, saya lebih suka tidak memiliki sesuatu yang baru untuk penanganan kesalahan daripada memiliki try() seperti yang diusulkan di sini.

Saya pribadi lebih menyukai proposal check sebelumnya, berdasarkan aspek visual semata; check memiliki kekuatan yang sama dengan try() ini tetapi bar(check foo()) lebih mudah dibaca oleh saya daripada bar(try(foo())) (saya hanya perlu satu detik untuk menghitung parens!).

Lebih penting lagi, keluhan utama saya tentang handle / check adalah bahwa ia tidak mengizinkan pembungkusan cek individu dengan cara yang berbeda -- dan sekarang proposal try() ini memiliki kelemahan yang sama, sambil menerapkan fitur penangguhan dan pengembalian bernama yang membingungkan bagi pemula yang jarang digunakan. Dan dengan handle setidaknya kami memiliki opsi untuk menggunakan cakupan untuk mendefinisikan blok pegangan, dengan defer bahkan itu tidak mungkin.

Sejauh yang saya ketahui, proposal ini kalah dari proposal handle / check sebelumnya dalam segala hal.

Inilah masalah lain dengan menggunakan penangguhan untuk penanganan kesalahan.

try adalah keluar yang dikendalikan/dimaksudkan dari suatu fungsi. menunda berjalan selalu, termasuk keluar tidak terkendali/tidak diinginkan dari fungsi. Ketidakcocokan itu dapat menyebabkan kebingungan. Berikut adalah skenario imajiner:

func someHTTPHandlerGuts() (err error) {
  defer func() {
    recordMetric("db call failed")
    return fmt.HandleErrorf("db unavailable: %v", err)
  }()
  data := try(makeDBCall)
  // some code that panics due to a bug
  return nil
}

Ingat bahwa net/http pulih dari kepanikan, dan bayangkan men-debug masalah produksi di sekitar kepanikan. Anda akan melihat instrumentasi Anda dan melihat lonjakan kegagalan panggilan db, dari panggilan recordMetric . Ini mungkin menutupi masalah sebenarnya, yaitu kepanikan di baris berikutnya.

Saya tidak yakin seberapa serius masalah ini dalam praktiknya, tetapi (sayangnya) mungkin alasan lain untuk berpikir bahwa penangguhan bukanlah mekanisme yang ideal untuk penanganan kesalahan.

Berikut adalah modifikasi yang dapat membantu mengatasi beberapa masalah yang muncul: Perlakukan try seperti goto alih-alih seperti return . Dengarkan aku. :)

try sebagai gantinya akan menjadi gula sintaksis untuk:

t1, … tn, te := f()  // t1, … tn, te are local (invisible) temporaries
if te != nil {
        err = te   // assign te to the error result parameter
        goto error // goto "error" label
}
x1, … xn = t1, … tn  // assignment only if there was no error

Manfaat:

• defer tidak diperlukan untuk menghias kesalahan. (Namun, pengembalian yang disebutkan masih diperlukan.)
• Keberadaan label error: adalah petunjuk visual bahwa ada try di suatu tempat dalam fungsi.

Ini juga menyediakan mekanisme untuk menambahkan penangan yang menghindari masalah penangan sebagai fungsi: Gunakan label sebagai penangan. try(fn(), wrap) akan goto wrap bukannya goto error . Kompiler dapat mengonfirmasi bahwa wrap: ada dalam fungsi. Perhatikan bahwa memiliki penangan juga membantu proses debug: Anda dapat menambahkan/mengubah penangan untuk menyediakan jalur debug.

Kode sampel:

func CopyFile(src, dst string) (err error) {
    r := try(os.Open(src))
    defer r.Close()

    w := try(os.Create(dst))
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if a “try” fails
        }
    }()

    try(io.Copy(w, r), copyfail)
    try(w.Close())
    return nil

error:
    return fmt.Errorf("copy %s %s: %v", src, dst, err)

copyfail:
    recordMetric("copy failure") // count incidents of this failure
    return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

Komentar lain:

• Kami mungkin ingin mengharuskan label apa pun yang digunakan sebagai target try didahului oleh pernyataan penghentian. Dalam praktiknya, ini akan memaksa mereka ke akhir fungsi dan dapat mencegah beberapa kode spageti. Di sisi lain, mungkin mencegah beberapa penggunaan yang masuk akal dan bermanfaat.
• try dapat digunakan untuk membuat loop. Saya pikir ini berada di bawah panji "jika sakit, jangan lakukan", tapi saya tidak yakin.
• Ini akan membutuhkan perbaikan https://github.com/golang/go/issues/26058 .

Kredit: Saya yakin varian dari ide ini pertama kali disarankan oleh @griesemer secara langsung di GopherCon tahun lalu.

@josharian Memikirkan interaksi dengan panic penting di sini, dan saya senang Anda mengemukakannya, tetapi contoh Anda tampak aneh bagi saya. Dalam kode berikut, tidak masuk akal bagi saya bahwa penangguhan selalu mencatat metrik "db call failed" . Ini akan menjadi metrik yang salah jika someHTTPHandlerGuts berhasil dan mengembalikan nil . defer berjalan di semua kasus keluar, bukan hanya kasus kesalahan atau panik, jadi kodenya tampak salah meskipun tidak ada kepanikan.

func someHTTPHandlerGuts() (err error) {
  defer func() {
    recordMetric("db call failed")
    return fmt.HandleErrorf("db unavailable: %v", err)
  }()
  data := try(makeDBCall)
  // some code that panics due to a bug
  return nil
}

@josharian Ya, ini kurang lebih persis versi yang kita bahas tahun lalu (kecuali bahwa kita menggunakan check bukannya try ). Saya pikir akan sangat penting bahwa seseorang tidak dapat melompat "kembali" ke seluruh badan fungsi, begitu kita berada di label error . Itu akan memastikan bahwa goto agak "terstruktur" (tidak mungkin kode spageti). Satu kekhawatiran yang diangkat adalah bahwa label error handler ( error: ) akan selalu berakhir di akhir fungsi (jika tidak, seseorang harus melompatinya entah bagaimana). Secara pribadi, saya suka kode penanganan kesalahan keluar dari jalan (di akhir), tetapi yang lain merasa itu harus terlihat tepat di awal.

@mikeshenkel Saya melihat kembali dari satu lingkaran sebagai nilai tambah daripada negatif. Dugaan saya adalah itu akan mendorong pengembang untuk menggunakan fungsi terpisah untuk menangani konten loop atau secara eksplisit menggunakan err seperti yang kita lakukan saat ini. Kedua hal ini tampak seperti hasil yang baik bagi saya.

Dari POV saya, saya tidak merasa sintaks try ini harus menangani setiap use case sama seperti saya tidak merasa perlu menggunakan

V, oke:= m[kunci]

Bentuk dari membaca dari peta

Anda dapat menghindari label goto yang memaksa penangan ke akhir fungsi dengan menghidupkan kembali proposal handle / check dalam bentuk yang disederhanakan. Bagaimana jika kita menggunakan sintaks handle err { ... } tetapi tidak membiarkan penangan berantai, sebaliknya hanya yang terakhir yang digunakan. Ini sangat menyederhanakan proposal itu, dan sangat mirip dengan ide goto, kecuali itu menempatkan penanganan lebih dekat ke titik penggunaan.

func CopyFile(src, dst string) (err error) {
    handle err {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    r := check os.Open(src)
    defer r.Close()

    w := check os.Create(dst)
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if a “check” fails
        }
    }()

    {
        // handlers are scoped, after this scope the original handle is used again.
        // as an alternative, we could have repeated the first handle after the io.Copy,
        // or come up with a syntax to name the handlers, though that's often not useful.
        handle err {
            recordMetric("copy failure") // count incidents of this failure
            return fmt.Errorf("copy %s %s: %v", src, dst, err)
        }
        check io.Copy(w, r)
    }
    check w.Close()
    return nil
}

Sebagai bonus, ini memiliki jalur masa depan untuk membiarkan rantai penangan, karena semua penggunaan yang ada akan memiliki pengembalian.

@josharian @griesemer jika Anda memperkenalkan penangan bernama (yang banyak tanggapan untuk diperiksa/ditangani, lihat tema berulang ), ada opsi sintaks yang lebih disukai daripada try(f(), err) :

try.err f()
try?err f()
try#err f()

?err    f() // because 'try' is redundant
?return f() // no handler
?panic  f() // no handler

(?err f()).method()

f?err() // lead with function name, instead of error handling
f?err().method()

file, ?err := os.Open(...) // many check/handle responses also requested this style

Salah satu hal yang paling saya sukai dari Go adalah sintaksnya relatif bebas tanda baca, dan dapat dibaca dengan keras tanpa masalah besar. Saya akan sangat membenci Go berakhir sebagai $#@!perl .

Bagi saya membuat "coba" fungsi bawaan dan mengaktifkan rantai memiliki 2 masalah:

• Ini tidak konsisten dengan aliran kontrol lainnya yang sedang berjalan (misalnya, kata kunci for/if/return/etc).
• Itu membuat kode kurang mudah dibaca.

Saya lebih suka membuat pernyataan tanpa tanda kurung. Contoh dalam proposal akan memerlukan banyak baris tetapi akan menjadi lebih mudah dibaca (yaitu, contoh "coba" individual akan lebih sulit untuk dilewatkan). Ya, itu akan merusak parser eksternal tetapi saya lebih suka menjaga konsistensi.

Operator ternary adalah tempat lain yang pergi tidak memiliki sesuatu dan membutuhkan lebih banyak penekanan tombol tetapi pada saat yang sama meningkatkan keterbacaan/pemeliharaan. Menambahkan "coba" dalam bentuk yang lebih terbatas ini akan lebih menyeimbangkan ekspresif vs keterbacaan, IMO.

FWIW, panic mempengaruhi aliran kontrol dan memiliki parens, tetapi go dan defer juga memengaruhi aliran dan tidak. Saya cenderung berpikir bahwa try lebih mirip dengan defer karena ini adalah operasi aliran yang tidak biasa dan membuatnya lebih sulit untuk dilakukan try (try os.Open(file)).Read(buf) baik karena kami ingin mencegah one-liners bagaimanapun, tapi apa pun. Baik baik saja.

Saran yang akan dibenci semua orang untuk nama implisit untuk variabel pengembalian kesalahan terakhir: $err . Ini lebih baik daripada try() IMO. :-)

@griesemer

_"Secara pribadi, saya suka kode penanganan kesalahan (di akhir)"_

+1 untuk itu!

Saya menemukan bahwa penanganan kesalahan yang diterapkan _sebelum_ kesalahan terjadi jauh lebih sulit untuk dijelaskan daripada penanganan kesalahan yang diterapkan _setelah_ kesalahan terjadi. Harus mental melompat mundur dan memaksa untuk mengikuti alur logika terasa seperti saya kembali pada tahun 1980 menulis Dasar dengan GOTOs.

Izinkan saya mengusulkan cara potensial lain untuk menangani kesalahan menggunakan CopyFile() sebagai contoh lagi:

func CopyFile(src, dst string) (err error) {

    r := os.Open(src)
    defer r.Close()

    w := os.Create(dst)
    defer w.Close()

    io.Copy(w, r)
    w.Close()

    for err := error {
        switch err.Source() {
        case w.Close:
            os.Remove(dst) // only if a “try” fails
            fallthrough
        case os.Open, os.Create, io.Copy:
            err = fmt.Errorf("copy %s %s: %v", src, dst, err)
        default:
            err = fmt.Errorf("an unexpected error occurred")
        }
    }

    return err
}

Perubahan bahasa yang diperlukan adalah:

1. Izinkan konstruksi for error{} , mirip dengan for range{} tetapi hanya dimasukkan jika ada kesalahan dan hanya dijalankan sekali.

2. Izinkan penghilangan pengambilan nilai kembalian yang mengimplementasikan <object>.Error() string tetapi hanya jika for error{} konstruk ada dalam func yang sama.

3. Menyebabkan aliran kontrol program melompat ke baris pertama dari konstruksi for error{} ketika func mengembalikan _"error"_ dalam nilai pengembalian terakhirnya.

4. Saat mengembalikan _"error"_ Go akan menambahkan assign referensi ke fungsi yang mengembalikan kesalahan yang seharusnya dapat diambil dengan <error>.Source()

Apa itu _"kesalahan"_?

Saat ini _"error"_ didefinisikan sebagai objek apa pun yang mengimplementasikan Error() string dan tentu saja bukan nil .

Namun, seringkali ada kebutuhan untuk memperluas kesalahan _bahkan pada keberhasilan_ untuk memungkinkan pengembalian nilai yang diperlukan untuk hasil sukses dari RESTful API. Jadi saya akan meminta agar tim Go jangan secara otomatis menganggap err!=nil berarti _"error"_ tetapi sebaliknya memeriksa apakah objek kesalahan mengimplementasikan IsError() dan jika IsError() mengembalikan true sebelum mengasumsikan bahwa nilai non- nil adalah _"error."_

_(Saya tidak harus berbicara tentang kode di perpustakaan standar tetapi terutama jika Anda memilih aliran kontrol Anda untuk bercabang pada _"error"_. Jika Anda hanya melihat err!=nil kita akan sangat terbatas dalam apa yang kita dapat dilakukan dalam hal mengembalikan nilai dalam fungsi kami.)_

BTW, mengizinkan semua orang untuk menguji _"error"_ dengan cara yang sama mungkin paling mudah dilakukan dengan menambahkan fungsi iserror() bawaan baru :

type ErrorIser interface {
    IsError() bool
}
func iserror(err error) bool {
    if err == nil { 
        return false
    }
    if _,ok := err.(ErrorIser); !ok {
        return true
    }
    return err.IsError()
}

Manfaat sampingan memungkinkan non-menangkap _"kesalahan"_

Perhatikan bahwa mengizinkan non-capturing _"error"_ terakhir dari panggilan func akan memungkinkan pemfaktoran ulang nanti untuk mengembalikan kesalahan dari func yang awalnya tidak perlu mengembalikan kesalahan. Dan itu akan memungkinkan refactoring ini tanpa merusak kode yang ada yang menggunakan bentuk pemulihan kesalahan ini dan panggilan mengatakan func s.

Bagi saya, keputusan _"Haruskah saya mengembalikan kesalahan atau melupakan penanganan kesalahan untuk memanggil kesederhanaan?"_ adalah salah satu kebingungan terbesar saya saat menulis kode Go. Mengizinkan tidak menangkap _"kesalahan"_ di atas akan menghilangkan kebingungan itu.

Saya sebenarnya mencoba menerapkan ide ini sebagai penerjemah Go sekitar setengah tahun yang lalu. Saya tidak memiliki pendapat yang kuat apakah fitur ini harus ditambahkan sebagai bawaan Go, tetapi izinkan saya berbagi pengalaman (walaupun saya tidak yakin itu berguna).

https://github.com/rhysd/trygo

Saya memanggil bahasa yang diperluas TryGo dan menerapkan penerjemah TryGo to Go.

Dengan penerjemah, kode

func CreateFileInSubdir(subdir, filename string, content []byte) error {
    cwd := try(os.Getwd())

    try(os.Mkdir(filepath.Join(cwd, subdir)))

    p := filepath.Join(cwd, subdir, filename)
    f := try(os.Create(p))
    defer f.Close()

    try(f.Write(content))

    fmt.Println("Created:", p)
    return nil
}

dapat diterjemahkan menjadi

func CreateFileInSubdir(subdir, filename string, content []byte) error {
    cwd, _err0 := os.Getwd()
    if _err0 != nil {
        return _err0
    }

    if _err1 := os.Mkdir(filepath.Join(cwd, subdir)); _err1 != nil {
        return _err1
    }

    p := filepath.Join(cwd, subdir, filename)
    f, _err2 := os.Create(p)
    if _err2 != nil {
        return _err2
    }
    defer f.Close()

    if _, _err3 := f.Write(content); _err3 != nil {
        return _err3
    }

    fmt.Println("Created:", p)
    return nil
}

Untuk batasan bahasa, saya tidak dapat mengimplementasikan panggilan try() generik. Hal ini dibatasi untuk

• RHS pernyataan definisi
• RHS pernyataan tugas
• Pernyataan panggilan

tapi saya bisa mencoba ini dengan proyek kecil saya. Pengalaman saya adalah

• ini pada dasarnya berfungsi dengan baik dan menghemat beberapa baris
• nilai pengembalian bernama sebenarnya tidak dapat digunakan untuk err karena nilai pengembalian fungsinya ditentukan oleh penugasan dan fungsi khusus try() . sangat membingungkan
• fungsi try() ini tidak memiliki fitur 'wrapping error' seperti yang dibahas di atas.

_"Keduanya tampak seperti hasil yang baik bagi saya."_

Kita harus setuju untuk tidak setuju di sini.

_"sintaks percobaan ini (tidak harus) menangani setiap kasus penggunaan"_

Meme itu mungkin yang paling meresahkan. Setidaknya mengingat seberapa tahan tim/komunitas Go terhadap perubahan apa pun di masa lalu yang tidak berlaku secara luas.

Jika kita mengizinkan pembenaran itu di sini, mengapa kita tidak dapat meninjau kembali proposal sebelumnya yang telah ditolak karena tidak dapat diterapkan secara luas?

Dan apakah kita sekarang terbuka untuk memperdebatkan perubahan di Go yang hanya berguna untuk kasus tepi yang dipilih?

Menurut perkiraan saya, menetapkan preseden ini tidak akan menghasilkan hasil yang baik dalam jangka panjang...

_"@mikeshenkel"_

PS Saya tidak melihat pesan Anda pada awalnya karena salah eja. _(ini tidak menyinggung saya, saya hanya tidak mendapatkan pemberitahuan ketika nama pengguna saya salah eja...)_

Saya menghargai komitmen untuk kompatibilitas ke belakang yang memotivasi Anda untuk menjadikan try sebagai bawaan, bukan kata kunci, tetapi setelah bergulat dengan _keanehan_ total memiliki fungsi yang sering digunakan yang dapat mengubah aliran kontrol ( panic dan recover sangat jarang), saya bertanya-tanya: adakah yang pernah melakukan analisis skala besar tentang frekuensi try sebagai pengenal dalam basis kode sumber terbuka? Saya penasaran dan skeptis, jadi saya melakukan pencarian awal di berikut ini:

• https://github.com/google/go-github
• https://github.com/cockroachdb/cockroach
• https://github.com/golang/net
• https://github.com/exercism/xgo
• https://github.com/GoogleCloudPlatform/kubernetes
• https://github.com/syncthing/syncthing
• https://github.com/mitchellh/packer
• https://github.com/drone/drone
• https://github.com/coreos/etcd
• https://github.com/docker/docker
• https://github.com/sjwhitworth/golearn
• https://github.com/bitly/nsq
• https://github.com/smartystreets/goconvey
• https://github.com/golang/tools
• https://github.com/coreos/fleet
• https://github.com/limetext/lime
• https://github.com/flynn/flynn
• https://github.com/dropbox/godropbox
• https://github.com/hashicorp/consul
• https://github.com/hashicorp/terraform

Dari 11.108.770 baris signifikan Go yang tinggal di repositori ini, hanya ada 63 instance try yang digunakan sebagai pengenal. Tentu saja, saya menyadari bahwa basis kode ini (walaupun besar, digunakan secara luas, dan penting dalam hak mereka sendiri) hanya mewakili sebagian kecil dari kode Go di luar sana, dan selain itu, kami tidak memiliki cara untuk menganalisis secara langsung basis kode pribadi, tetapi tentu saja hasil yang menarik.

Selain itu, karena try , seperti kata kunci lainnya, adalah huruf kecil, Anda tidak akan pernah menemukannya di API publik sebuah paket. Penambahan kata kunci hanya akan memengaruhi internal paket.

Ini semua adalah kata pengantar untuk beberapa ide yang ingin saya masukkan ke dalam campuran yang akan mendapat manfaat dari try sebagai kata kunci.

Saya akan mengusulkan konstruksi berikut.

1) Tidak ada penangan

// The existing proposal, but as a keyword rather than builtin.  When an error is 
// "caught", the function returns all zero values plus the error.  Nothing 
// particularly new here.
func doSomething() (int, error) {
    try SomeFunc()
    a, b := try AnotherFunc()

    // ...

    return 123, nil
}

2) Penangan

Perhatikan bahwa penangan kesalahan adalah blok kode sederhana, dimaksudkan untuk digariskan, bukan fungsi. Lebih lanjut tentang ini di bawah ini.

func doSomething() (int, error) {
    // Inline error handler
    a, b := try SomeFunc() else err {
        return 0, errors.Wrap(err, "error in doSomething:")
    }

    // Named error handlers
    handler logAndContinue err {
        log.Errorf("non-critical error: %v", err)
    }
    handler annotateAndReturn err {
        return 0, errors.Wrap(err, "error in doSomething:")
    }

    c, d := try SomeFunc() else logAndContinue
    e, f := try OtherFunc() else annotateAndReturn

    // ...

    return 123, nil
}

Pembatasan yang diusulkan:

• Anda hanya dapat try panggilan fungsi. Tidak try err .
• Jika Anda tidak menentukan handler, Anda hanya dapat try dari dalam fungsi yang mengembalikan kesalahan sebagai nilai pengembalian paling kanan. Tidak ada perubahan dalam perilaku try berdasarkan konteksnya. Itu tidak pernah panik (seperti yang dibahas lebih awal di utas).
• Tidak ada "rantai pawang" dalam bentuk apa pun. Penangan hanyalah blok kode yang tidak dapat disejajarkan.

Manfaat:

• Sintaks try / else dapat disederhanakan menjadi "compound if" yang ada:
  go a, b := try SomeFunc() else err { return 0, errors.Wrap(err, "error in doSomething:") }
  menjadi
  go if a, b, err := SomeFunc(); err != nil { return 0, errors.Wrap(err, "error in doSomething:") }
  Bagi saya, gabungan if selalu tampak lebih membingungkan daripada membantu karena alasan yang sangat sederhana: kondisional umumnya terjadi _setelah_ operasi, dan ada hubungannya dengan pemrosesan hasilnya. Jika operasi terjepit di dalam pernyataan bersyarat, itu hanya kurang jelas bahwa itu terjadi. Mata terganggu. Lebih jauh lagi, ruang lingkup variabel yang ditentukan tidak segera terlihat seperti ketika mereka berada paling kiri pada sebuah baris.
• Penangan kesalahan sengaja tidak didefinisikan sebagai fungsi (atau dengan apa pun yang menyerupai semantik seperti fungsi). Ini melakukan beberapa hal untuk kami:
  
  
  
  • Kompiler dapat dengan mudah memasukkan handler bernama di mana pun ia dirujuk. Ini lebih seperti templat makro/kodegen sederhana daripada panggilan fungsi. Runtime bahkan tidak perlu tahu bahwa penangan ada.
  
  
  • Kami tidak terbatas pada apa yang bisa kami lakukan di dalam handler. Kami mengatasi kritik check / handle bahwa "kerangka kerja penanganan kesalahan ini hanya baik untuk dana talangan". Kami juga mengatasi kritik "rantai penangan". Kode arbitrer apa pun dapat ditempatkan di dalam salah satu penangan ini, dan tidak ada aliran kontrol lain yang tersirat.
  
  
  • Kita tidak perlu membajak return di dalam handler untuk mengartikan super return . Membajak kata kunci sangat membingungkan. return hanya berarti return , dan sebenarnya tidak perlu super return .
  
  
  • defer tidak perlu cahaya bulan sebagai mekanisme penanganan kesalahan. Kita dapat terus memikirkannya terutama sebagai cara untuk membersihkan sumber daya, dll.
  
  
• Mengenai menambahkan konteks ke kesalahan:
  
  
  
  • Menambahkan konteks dengan penangan sangat sederhana dan terlihat sangat mirip dengan blok if err != nil yang ada
  
  
  • Meskipun konstruk "coba tanpa penangan" tidak secara langsung mendorong penambahan konteks, sangat mudah untuk memfaktorkan ulang ke dalam bentuk penangan. Penggunaannya yang dimaksudkan terutama selama pengembangan, dan akan sangat mudah untuk menulis cek go vet untuk menyoroti kesalahan yang tidak tertangani.
  
  

Mohon maaf jika ide-ide ini sangat mirip dengan proposal lain — saya telah mencoba mengikuti semuanya, tetapi mungkin banyak yang terlewatkan.

@brynbellomy Terima kasih untuk analisis kata kunci - itu informasi yang sangat membantu. Tampaknya try sebagai kata kunci mungkin baik-baik saja. (Anda mengatakan bahwa API tidak terpengaruh - itu benar, tetapi try mungkin masih muncul sebagai nama parameter atau sejenisnya - jadi dokumentasi mungkin harus diubah. Tapi saya setuju bahwa itu tidak akan memengaruhi klien dari paket-paket itu.)

Mengenai proposal Anda: Itu akan baik-baik saja bahkan tanpa penangan bernama, bukan? (Itu akan menyederhanakan proposal tanpa kehilangan daya. Seseorang cukup memanggil fungsi lokal dari handler inline.)

Mengenai proposal Anda: Itu akan baik-baik saja bahkan tanpa penangan bernama, bukan? (Itu akan menyederhanakan proposal tanpa kehilangan daya. Seseorang cukup memanggil fungsi lokal dari handler inline.)

@griesemer Memang — Saya merasa cukup suam-suam kuku tentang memasukkan itu. Tentu saja lebih Go-ish tanpa.

Di sisi lain, tampaknya orang menginginkan kemampuan untuk melakukan penanganan kesalahan satu baris, termasuk satu baris yang return . Kasus tipikal adalah log, lalu return . Jika kita keluar ke fungsi lokal di klausa else , kita mungkin kehilangan itu:

a, b := try SomeFunc() else err {
    someLocalFunc(err)
    return 0, err
}

(Saya masih lebih suka ini untuk menggabungkan jika)

Namun, Anda masih bisa mendapatkan pengembalian satu baris yang menambahkan konteks kesalahan dengan menerapkan tweak gofmt sederhana yang dibahas sebelumnya di utas:

a, b := try SomeFunc() else err { return 0, errors.Wrap(err, "bad stuff!") }

Apakah kata kunci baru diperlukan dalam proposal di atas? Kenapa tidak:

SomeFunc() else return
a, b := SomeOtherFunc() else err { return 0, errors.Wrap(err, "bad stuff!") }

@griesemer jika penangan kembali, saya sarankan Anda membuat masalah baru untuk diskusi try/handle atau try/_label_. Proposal ini secara khusus menghilangkan penangan, dan ada banyak cara untuk mendefinisikan dan memanggilnya.

Siapa pun yang menyarankan penangan harus terlebih dahulu membaca cek/menangani umpan balik wiki. Kemungkinannya bagus bahwa apa pun yang Anda impikan sudah dijelaskan di sana :-)
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback

@smonkewitz tidak, kata kunci baru tidak diperlukan dalam versi itu karena terikat dengan pernyataan penugasan, yang sejauh ini telah disebutkan beberapa kali dalam berbagai sintaks gula.

https://github.com/golang/go/issues/32437#issuecomment -499808741
https://github.com/golang/go/issues/32437#issuecomment -499852124
https://github.com/golang/go/issues/32437#issuecomment -50095505

@ianlancetaylor apakah penanganan kesalahan ini sudah dipertimbangkan oleh tim go? Implementasinya tidak semudah yang diusulkan, tetapi terasa lebih idiomatis. ~pernyataan yang tidak perlu, maaf.~

Saya ingin mengulangi sesuatu yang @deanveloper dan beberapa orang lain katakan, tetapi dengan penekanan saya sendiri. Di https://github.com/golang/go/issues/32437#issuecomment -498939499 @deanveloper berkata:

try adalah pengembalian bersyarat. Aliran kontrol DAN pengembalian keduanya ditahan di atas tumpuan di Go. Semua aliran kontrol dalam suatu fungsi diindentasi, dan semua pengembalian dimulai dengan return . Menggabungkan kedua konsep ini bersama-sama menjadi panggilan fungsi yang mudah terlewatkan terasa agak aneh.

Selanjutnya, dalam proposal ini try adalah fungsi yang mengembalikan nilai, sehingga dapat digunakan sebagai bagian dari ekspresi yang lebih besar.

Beberapa berpendapat bahwa panic telah menetapkan preseden untuk fungsi bawaan yang mengubah aliran kontrol, tetapi saya pikir panic dasarnya berbeda karena dua alasan:

1. Panik tidak bersyarat; itu selalu membatalkan fungsi panggilan.
2. Panic tidak mengembalikan nilai apa pun dan dengan demikian hanya dapat muncul sebagai pernyataan mandiri, yang meningkatkan visibilitasnya.

Coba di sisi lain:

1. Bersyarat; itu mungkin atau mungkin tidak kembali dari fungsi panggilan.
2. Mengembalikan nilai dan dapat muncul dalam ekspresi majemuk, mungkin beberapa kali, pada satu baris, berpotensi melewati margin kanan jendela editor saya.

Untuk alasan ini saya pikir try terasa lebih dari "sedikit", saya pikir itu pada dasarnya merusak keterbacaan kode.

Hari ini, ketika kami menemukan beberapa kode Go untuk pertama kalinya, kami dapat dengan cepat menelusurinya untuk menemukan kemungkinan titik keluar dan mengontrol titik aliran. Saya percaya itu adalah properti kode Go yang sangat berharga. Menggunakan try menjadi terlalu mudah untuk menulis kode yang tidak memiliki properti tersebut.

Saya akui bahwa kemungkinan pengembang Go yang menghargai keterbacaan kode akan berkumpul pada idiom penggunaan untuk try yang menghindari jebakan keterbacaan ini. Saya harap itu akan terjadi karena keterbacaan kode tampaknya menjadi nilai inti bagi banyak pengembang Go. Tetapi tidak jelas bagi saya bahwa try menambahkan nilai yang cukup pada idiom kode yang ada untuk membawa beban menambahkan konsep baru ke bahasa untuk dipelajari semua orang dan itu dapat dengan mudah merusak keterbacaan.

````
jika != "rusak" {
jangan perbaiki
}

@ChrisHines Untuk poin Anda (yang digaungkan di tempat lain di utas ini), mari tambahkan batasan lain:

• setiap pernyataan try (bahkan yang tidak memiliki handler) harus muncul pada barisnya sendiri.

Anda masih akan mendapat manfaat dari pengurangan kebisingan visual yang besar. Kemudian, Anda telah menjamin pengembalian yang dianotasi oleh return dan pengembalian bersyarat yang dianotasi oleh try , dan kata kunci tersebut selalu berdiri di awal baris (atau paling buruk, langsung setelah penetapan variabel).

Jadi, tidak satu pun dari jenis omong kosong ini:

try EmitEvent(try (try DecodeMsg(m)).SaveToDB())

melainkan ini:

dm := try DecodeMsg(m)
um := try dm.SaveToDB()
try EmitEvent(um)

yang masih terasa lebih jelas dari ini:

dm, err := DecodeMsg(m)
if err != nil {
    return nil, err
}

um, err := dm.SaveToDB()
if err != nil {
    return nil, err
}

err = EmitEvent(um)
if err != nil {
    return nil, err
}

Satu hal yang saya suka tentang desain ini adalah bahwa tidak mungkin untuk mengabaikan kesalahan secara diam-diam tanpa tetap menjelaskan bahwa kesalahan itu mungkin terjadi . Sedangkan sekarang, Anda kadang-kadang melihat x, _ := SomeFunc() (apa nilai pengembalian yang diabaikan? kesalahan? sesuatu yang lain?), sekarang Anda harus membubuhi keterangan dengan jelas:

x := try SomeFunc() else err {}

Sejak posting saya sebelumnya untuk mendukung proposal tersebut, saya telah melihat dua ide yang diposting oleh @jagv (tanpa parameter try mengembalikan *error ) dan oleh @josharian (penangan kesalahan berlabel) yang saya percaya pada bentuk yang sedikit dimodifikasi akan sangat meningkatkan proposal.

Menyatukan ide-ide ini dengan ide lain yang saya miliki sendiri, kami akan memiliki empat versi try :

1. mencoba()
2. coba (params)
3. coba (params, label)
4. coba (params, panik)

1 hanya akan mengembalikan pointer ke parameter pengembalian kesalahan (ERP) atau nihil jika tidak ada (hanya #4). Ini akan memberikan alternatif untuk ERP bernama tanpa perlu menambahkan built-in lebih lanjut.

2 akan bekerja persis seperti yang dibayangkan saat ini. Kesalahan non-nol akan segera dikembalikan tetapi dapat didekorasi dengan pernyataan defer .

3 akan berfungsi seperti yang disarankan oleh @josharian yaitu pada kesalahan non-nol kode akan bercabang ke label. Namun, tidak akan ada label penangan kesalahan default karena kasus itu sekarang akan berubah menjadi #2.

Tampaknya bagi saya bahwa ini biasanya akan menjadi cara yang lebih baik untuk mendekorasi kesalahan (atau menanganinya secara lokal dan kemudian mengembalikan nihil) daripada defer karena lebih sederhana dan lebih cepat. Siapa saja yang tidak suka masih bisa menggunakan #2.

Ini akan menjadi praktik terbaik untuk menempatkan label/kode penanganan kesalahan di dekat akhir fungsi dan tidak melompat kembali ke seluruh badan fungsi. Namun, saya tidak berpikir kompiler harus menegakkan baik karena mungkin ada kesempatan aneh di mana mereka berguna dan penegakan mungkin sulit dalam hal apa pun.

Jadi label normal dan perilaku goto akan menerapkan subjek (seperti yang dikatakan @josharian ) ke #26058 diperbaiki terlebih dahulu tetapi saya pikir itu harus tetap diperbaiki.

Nama label tidak boleh panic karena akan bertentangan dengan #4.

4 akan panic segera daripada kembali atau bercabang. Akibatnya, jika ini adalah satu-satunya versi try yang digunakan dalam fungsi tertentu, ERP tidak diperlukan.

Saya telah menambahkan ini sehingga paket pengujian dapat berfungsi seperti sekarang tanpa perlu lebih lanjut built-in atau perubahan lainnya. Namun, ini mungkin berguna dalam skenario _fatal_ lainnya juga.

Ini perlu menjadi versi terpisah dari try sebagai alternatif percabangan ke penangan kesalahan dan kemudian panik dari itu masih memerlukan ERP.

Salah satu jenis reaksi terkuat terhadap proposal awal adalah kekhawatiran seputar hilangnya visibilitas aliran normal tempat fungsi kembali.

Misalnya, @deanveloper mengungkapkan kekhawatiran itu dengan sangat baik di https://github.com/golang/go/issues/32437#issuecomment -498932961, yang menurut saya merupakan komentar dengan suara terbanyak di sini.

@dominikh menulis di https://github.com/golang/go/issues/32437#issuecomment -499067357:

Dalam kode gofmt'ed, return selalu cocok dengan /^\t*return / – ini adalah pola yang sangat sepele untuk dilihat, tanpa bantuan apa pun. coba, di sisi lain, dapat terjadi di mana saja dalam kode, bersarang secara sewenang-wenang jauh di dalam panggilan fungsi. Tidak ada jumlah pelatihan yang akan membuat kita dapat segera melihat semua aliran kontrol dalam suatu fungsi tanpa bantuan alat.

Untuk membantu dengan itu, @brynbellomy menyarankan kemarin:

setiap pernyataan try (bahkan yang tanpa handler) harus muncul pada barisnya sendiri.

Lebih jauh lagi, try dapat diminta untuk menjadi awal baris, bahkan untuk sebuah tugas.

Jadi bisa jadi:

try dm := DecodeMsg(m)
try um := dm.SaveToDB()
try EmitEvent(um)

daripada yang berikut (dari contoh @brynbellomy ):

dm, err := DecodeMsg(m)
if err != nil {
    return nil, err
}

um, err := dm.SaveToDB()
if err != nil {
    return nil, err
}

err = EmitEvent(um)
if err != nil {
    return nil, err
}

Tampaknya itu akan mempertahankan visibilitas yang cukup, bahkan tanpa bantuan editor atau IDE, sambil tetap mengurangi boilerplate.

Itu bisa bekerja dengan pendekatan berbasis penangguhan yang saat ini diusulkan yang bergantung pada parameter hasil bernama, atau bisa bekerja dengan menentukan fungsi penangan normal. (Menentukan fungsi handler tanpa memerlukan nilai pengembalian bernama tampaknya lebih baik bagi saya daripada membutuhkan nilai pengembalian bernama, tetapi itu adalah poin terpisah).

Proposal mencakup contoh ini:

info := try(try(os.Open(file)).Stat())    // proposed try built-in

Itu bisa saja:

try f := os.Open(file)
try info := f.Stat()

Itu masih pengurangan boilerplate dibandingkan dengan apa yang mungkin ditulis seseorang hari ini, bahkan jika tidak sesingkat sintaks yang diusulkan. Mungkin itu akan cukup singkat?

@elagergren-spideroak memberikan contoh ini:

try(try(try(to()).parse().this)).easily())

Saya pikir itu memiliki parens yang tidak cocok, yang mungkin merupakan poin yang disengaja atau sedikit humor yang halus, jadi saya tidak yakin apakah contoh itu bermaksud memiliki 2 try atau 3 try . Bagaimanapun, mungkin akan lebih baik untuk meminta penyebaran itu di 2-3 baris yang dimulai dengan try .

@thepudds , inilah yang saya maksud di komentar saya sebelumnya. Kecuali yang diberikan

try f := os.Open(file)
try info := f.Stat()

Hal yang jelas untuk dilakukan adalah menganggap try sebagai blok coba di mana lebih dari satu kalimat dapat dimasukkan ke dalam tanda kurung . Jadi yang di atas bisa menjadi

try (
    f := os.Open(file)
    into := f.Stat()
)

Jika kompiler tahu bagaimana menangani ini, hal yang sama juga berfungsi untuk bersarang. Jadi sekarang di atas bisa menjadi

try info := os.Open(file).Stat()

Dari tanda tangan fungsi, kompiler mengetahui bahwa Open dapat mengembalikan nilai kesalahan dan seperti dalam blok coba, perlu menghasilkan penanganan kesalahan dan kemudian memanggil Stat() pada nilai utama yang dikembalikan dan seterusnya.

Hal berikutnya adalah mengizinkan pernyataan di mana tidak ada nilai kesalahan yang dihasilkan atau ditangani secara lokal. Jadi sekarang Anda bisa mengatakan

try (
    f := os.Open(file)
    debug("f: %v\n", f) // debug returns nothing
    into := f.Stat()
)

Ini memungkinkan kode yang berkembang tanpa harus mengatur ulang blok percobaan. Tetapi untuk beberapa alasan aneh orang tampaknya berpikir bahwa penanganan kesalahan harus dijabarkan secara eksplisit! Mereka ingin

try(try(try(to()).parse()).this)).easily())

Sementara saya baik-baik saja dengan

try to().parse().this().easily()

Meskipun dalam kedua kasus kode pengecekan kesalahan yang sama dapat dihasilkan. Pandangan saya adalah Anda selalu dapat menulis kode khusus untuk penanganan kesalahan jika perlu. try (atau apa pun yang Anda suka menyebutnya) cukup mendeklarasikan penanganan kesalahan default (yaitu untuk menyepaknya ke pemanggil).

Manfaat lain adalah jika kompiler menghasilkan penanganan kesalahan default, ia dapat menambahkan beberapa informasi pengenal lainnya sehingga Anda tahu mana dari empat fungsi di atas yang gagal.

Saya agak khawatir tentang keterbacaan program di mana try muncul di dalam ekspresi lain. Jadi saya menjalankan grep "return .*err$" di perpustakaan standar dan mulai membaca blok secara acak. Ada 7214 hasil, saya hanya membaca beberapa ratus.

Hal pertama yang perlu diperhatikan adalah di mana try berlaku, itu membuat hampir semua blok ini sedikit lebih mudah dibaca.

Hal kedua adalah bahwa sangat sedikit dari ini, kurang dari 1 dari 10, akan menempatkan try di dalam ekspresi lain. Kasus tipikal adalah pernyataan dalam bentuk x := try(...) atau ^try(...)$ .

Berikut adalah beberapa contoh di mana try akan muncul di dalam ekspresi lain:

teks/templat

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        lessOrEqual, err := le(arg1, arg2)
        if err != nil {
                return false, err
        }
        return !lessOrEqual, nil
}

menjadi:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        return !try(le(arg1, arg2)), nil
}

teks/templat

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
...
        switch v.Kind() {
        case reflect.Map:
                index, err := prepareArg(index, v.Type().Key())
                if err != nil {
                        return reflect.Value{}, err
                }
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

menjadi

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                if x := v.MapIndex(try(prepareArg(index, v.Type().Key()))); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

(ini adalah contoh yang paling dipertanyakan yang saya lihat)

regexp/sintaks:

regexp/syntax/parse.go

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        if c, t, err = nextRune(t); err != nil {
                return nil, err
        }
        p.literal(c)
        ...
}

menjadi

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        c, t = try(nextRune(t))
        p.literal(c)
        ...
}

Ini bukan contoh percobaan di dalam ekspresi lain tetapi saya ingin menyebutnya karena meningkatkan keterbacaan. Jauh lebih mudah untuk melihat di sini bahwa nilai c dan t hidup di luar cakupan pernyataan if.

bersih/http

net/http/request.go:readRequest

        mimeHeader, err := tp.ReadMIMEHeader()
        if err != nil {
                return nil, err
        }
        req.Header = Header(mimeHeader)

menjadi:

        req.Header = Header(try(tp.ReadMIMEHeader())

database/sql

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                connector, err := driverCtx.OpenConnector(dataSourceName)
                if err != nil {
                        return nil, err
                }
                return OpenDB(connector), nil
        }

menjadi

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                return OpenDB(try(driverCtx.OpenConnector(dataSourceName))), nil
        }

database/sql

        si, err := ctxDriverPrepare(ctx, dc.ci, query)
        if err != nil {
                return nil, err
        }
        ds := &driverStmt{Locker: dc, si: si}

menjadi

        ds := &driverStmt{
                Locker: dc,
                si: try(ctxDriverPrepare(ctx, dc.ci, query)),
        }

bersih/http

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                cc, err := p.t.dialclientconn(addr, singleuse)
                if err != nil {
                        return nil, err
                }
                return cc, nil
        }

menjadi

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                return try(p.t.dialclientconn(addr, singleuse))
        }

bersih/http

func (f *http2Framer) endWrite() error {
        ...
        n, err := f.w.Write(f.wbuf)
        if err == nil && n != len(f.wbuf) {
                err = io.ErrShortWrite
        }
        return err
}

menjadi

func (f *http2Framer) endWrite() error {
        ...
        if try(f.w.Write(f.wbuf) != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

(Yang ini saya sangat suka.)

bersih/http

        if f, err := fr.ReadFrame(); err != nil {
                return nil, err
        } else {
                hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
        }

menjadi

        hc = try(fr.ReadFrame()).(*http2ContinuationFrame)// guaranteed by checkFrameOrder

}

(Juga bagus.)

bersih :

        if ctrlFn != nil {
                c, err := newRawConn(fd)
                if err != nil {
                        return err
                }
                if err := ctrlFn(fd.ctrlNetwork(), laddr.String(), c); err != nil {
                        return err
                }
        }

menjadi

        if ctrlFn != nil {
                try(ctrlFn(fd.ctrlNetwork(), laddr.String(), try(newRawConn(fd))))
        }

mungkin ini terlalu banyak, dan sebaliknya seharusnya:

        if ctrlFn != nil {
                c := try(newRawConn(fd))
                try(ctrlFn(fd.ctrlNetwork(), laddr.String(), c))
        }

Secara keseluruhan, saya cukup menikmati efek try pada kode perpustakaan standar yang saya baca.

Satu poin terakhir: Melihat try diterapkan untuk membaca kode di luar beberapa contoh dalam proposal itu mencerahkan. Saya pikir perlu mempertimbangkan untuk menulis alat untuk secara otomatis mengonversi kode untuk menggunakan try (di mana itu tidak mengubah semantik program). Akan menarik untuk membaca contoh perbedaan yang dihasilkan terhadap paket-paket populer di github untuk melihat apakah apa yang saya temukan di perpustakaan standar bertahan. Keluaran program semacam itu dapat memberikan wawasan tambahan tentang pengaruh proposal.

@crawshaw terima kasih telah melakukan ini, senang melihatnya beraksi. Tetapi melihatnya dalam tindakan membuat saya menganggap lebih serius argumen terhadap penanganan kesalahan inline yang sampai sekarang saya abaikan.

Karena ini sangat dekat dengan saran menarik @thepudds untuk membuat pernyataan try , saya menulis ulang semua contoh menggunakan sintaks itu dan menemukannya jauh lebih jelas daripada ekspresi- try atau status quo, tanpa memerlukan terlalu banyak baris tambahan:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                try index := prepareArg(index, v.Type().Key())
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        try c, t = nextRune(t)
        p.literal(c)
        ...
}

        try mimeHeader := tp.ReadMIMEHeader()
        req.Header = Header(mimeHeader)

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                try connector := driverCtx.OpenConnector(dataSourceName)
                return OpenDB(connector), nil
        }

Yang ini bisa dibilang lebih baik dengan ekspresi- try jika ada beberapa bidang yang harus try -ed, tapi saya masih lebih suka keseimbangan trade off ini

        try si := ctxDriverPrepare(ctx, dc.ci, query)
        ds := &driverStmt{Locker: dc, si: si}

Ini pada dasarnya adalah kasus terburuk untuk ini dan terlihat baik-baik saja:

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                try cc := p.t.dialclientconn(addr, singleuse)
                return cc, nil
        }

Saya berdebat dengan diri saya sendiri apakah if try akan atau harus legal, tetapi saya tidak dapat memberikan penjelasan yang masuk akal mengapa itu tidak boleh dan itu bekerja dengan cukup baik di sini:

func (f *http2Framer) endWrite() error {
        ...
        if try n := f.w.Write(f.wbuf); n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

        try f := fr.ReadFrame()
        hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder

        if ctrlFn != nil {
                try c := newRawConn(fd)
                try ctrlFn(fd.ctrlNetwork(), laddr.String(), c)
        }

Memindai melalui contoh @crawshaw hanya membuat saya merasa lebih yakin bahwa aliran kontrol akan sering dibuat cukup samar untuk lebih berhati-hati tentang desain. Menghubungkan bahkan sejumlah kecil kompleksitas menjadi sulit dibaca dan mudah rusak. Saya senang melihat opsi dipertimbangkan, tetapi aliran kontrol yang rumit dalam bahasa yang dijaga seperti itu tampaknya sangat tidak sesuai karakter.

func (f *http2Framer) endWrite() error {
        ...
        if try(f.w.Write(f.wbuf) != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

Juga, try tidak "mencoba" apa pun. Ini adalah "relai pelindung". Jika semantik dasar proposal mati, saya tidak heran kode yang dihasilkan juga bermasalah.

func (f *http2Framer) endWrite() error {
        ...
        relay n := f.w.Write(f.wbuf)
        return checkShortWrite(n, len(f.wbuf))
}

Jika Anda membuat pernyataan try, Anda bisa menggunakan flag untuk menunjukkan nilai yang dikembalikan, dan tindakan apa:

try c, @      := newRawConn(fd) // return
try c, <strong i="6">@panic</strong> := newRawConn(fd) // panic
try c, <strong i="7">@hname</strong> := newRawConn(fd) // invoke named handler
try c, <strong i="8">@_</strong>     := newRawConn(fd) // ignore, or invoke "ignored" handler if defined

Anda masih memerlukan sintaks sub-ekspresi (Russ telah menyatakan itu persyaratan), setidaknya untuk panik dan mengabaikan tindakan.

Pertama, saya memuji @crawshaw karena meluangkan waktu untuk melihat sekitar 200 contoh nyata dan meluangkan waktu untuk tulisannya yang bijaksana di atas.

Kedua, @jimmyfrasche , mengenai tanggapan Anda di sini tentang contoh http2Framer :

Saya berdebat dengan diri sendiri apakah if try akan atau harus legal, tetapi saya tidak dapat memberikan penjelasan yang masuk akal mengapa itu tidak boleh dan itu bekerja dengan cukup baik di sini:

```
func (f *http2Framer) endWrite() kesalahan {
...
jika mencoba n := fwWrite(f.wbuf); n != len(f.wbuf) {
kembalikan io.ErrShortWrite
}
kembali nihil
}

At least under what I was suggesting above in https://github.com/golang/go/issues/32437#issuecomment-500213884, under that proposal variation I would suggest `if try` is not allowed.

That `http2Framer` example could instead be:

func (f *http2Framer) endWrite() kesalahan {
...
coba n := fwWrite(f.wbuf)
jika n != len(f.wbuf) {
kembalikan io.ErrShortWrite
}
kembali nihil
}
`` That is one line longer, but hopefully still "light on the page". Personally, I think that (arguably) reads more cleanly, but more importantly it is easier to see the coba`.

@deanveloper menulis di atas di https://github.com/golang/go/issues/32437#issuecomment -498932961:

Kembali dari suatu acara tampaknya merupakan hal yang "suci" untuk dilakukan

Contoh spesifik http2Framer itu akhirnya tidak sesingkat mungkin. Namun, ini menahan pengembalian dari fungsi yang lebih "suci" jika try harus menjadi hal pertama dalam sebuah baris.

@crawshaw menyebutkan:

Hal kedua adalah bahwa sangat sedikit dari ini, kurang dari 1 dari 10, akan mencoba di dalam ekspresi lain. Kasus tipikal adalah pernyataan dalam bentuk x := try(...) atau ^try(...)$.

Mungkin tidak apa-apa untuk hanya membantu sebagian dari 1 dari 10 contoh tersebut dengan bentuk try yang lebih terbatas, terutama jika kasus tipikal dari contoh tersebut berakhir dengan jumlah baris yang sama meskipun try adalah diperlukan untuk menjadi hal pertama dalam satu baris?

@jimmyfrasche

@crawshaw terima kasih telah melakukan ini, senang melihatnya beraksi. Tetapi melihatnya dalam tindakan membuat saya menganggap lebih serius argumen terhadap penanganan kesalahan inline yang sampai sekarang saya abaikan.

Karena ini sangat dekat dengan saran menarik @thepudds untuk membuat pernyataan try , saya menulis ulang semua contoh menggunakan sintaks itu dan menemukannya jauh lebih jelas daripada ekspresi- try atau status quo, tanpa memerlukan terlalu banyak baris tambahan:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

Contoh pertama Anda menggambarkan dengan baik mengapa saya sangat menyukai ekspresi- try . Dalam versi Anda, saya harus memasukkan hasil panggilan ke le dalam variabel, tetapi variabel itu tidak memiliki arti semantik yang belum disiratkan oleh istilah le . Jadi tidak ada nama yang bisa saya berikan yang tidak berarti (seperti x ) atau berlebihan (seperti lessOrEqual ). Dengan ekspresi- try , tidak diperlukan variabel perantara, jadi masalah ini bahkan tidak muncul.

Saya lebih suka tidak perlu mengeluarkan upaya mental untuk menemukan nama untuk hal-hal yang lebih baik dibiarkan anonim.

Saya senang untuk memberikan dukungan saya di belakang beberapa posting terakhir di mana try (kata kunci) telah dipindahkan ke awal baris. Itu benar-benar harus berbagi ruang visual yang sama dengan return .

Re: Saran @jimmyfrasche untuk mengizinkan try dalam pernyataan gabungan if , itulah hal yang saya pikir banyak orang di sini coba hindari, karena beberapa alasan:

• itu menggabungkan dua mekanisme aliran kontrol yang sangat berbeda menjadi satu baris
• ekspresi try sebenarnya dievaluasi terlebih dahulu, dan dapat menyebabkan fungsi kembali, namun muncul setelah if
• mereka kembali dengan kesalahan yang sama sekali berbeda, salah satunya tidak benar-benar kita lihat dalam kode, dan satu yang kita lakukan
• itu membuatnya kurang jelas bahwa try sebenarnya tidak tertangani, karena blok tersebut sangat mirip dengan blok penangan (walaupun menangani masalah yang sama sekali berbeda)

Seseorang dapat mendekati situasi ini dari sudut yang sedikit berbeda yang mendukung mendorong orang untuk menangani try s. Bagaimana dengan mengizinkan sintaks try / else berisi kondisional berikutnya (yang merupakan pola umum dengan banyak fungsi I/O yang mengembalikan err dan n , salah satunya mungkin menunjukkan masalah):

func (f *http2Framer) endWrite() error {
        // ...
        try n := f.w.Write(f.wbuf) else err {
                return errors.Wrap(err, "error writing:")
        } else if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

Jika Anda tidak menangani kesalahan yang dikembalikan oleh .Write , Anda masih memiliki anotasi yang jelas bahwa .Write mungkin salah (seperti yang ditunjukkan oleh @thepudds):

func (f *http2Framer) endWrite() error {
        // ...
        try n := f.w.Write(f.wbuf)
        if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

Saya menggandakan tanggapan @daved . Menurut pendapat saya, setiap contoh yang disorot oleh @crawshaw menjadi kurang jelas dan lebih rawan kesalahan sebagai akibat dari try .

Saya senang untuk memberikan dukungan saya di belakang beberapa posting terakhir di mana try (kata kunci) telah dipindahkan ke awal baris. Itu benar-benar harus berbagi ruang visual yang sama dengan return .

Mengingat dua opsi untuk poin ini dan dengan asumsi bahwa satu dipilih dan dengan demikian menjadi preseden untuk fitur potensial di masa depan:

SEBUAH.)

try f := os.Open(filepath) else err {
    return errors.Wrap(err, "can't open")
}

B.)

f := try os.Open(filepath) else err {
    return errors.Wrap(err, "can't open")
}

Manakah dari keduanya yang memberikan lebih banyak fleksibilitas untuk penggunaan kata kunci baru di masa mendatang? _(Saya tidak tahu jawabannya karena saya belum menguasai seni gelap menulis kompiler.)_ Apakah satu pendekatan akan lebih membatasi daripada yang lain?

@davecheney @daved @crawshaw
Saya cenderung setuju dengan Daves yang satu ini: dalam contoh @crawshaw , ada banyak pernyataan try yang tertanam jauh di dalam baris yang memiliki banyak hal lain yang terjadi. Sangat sulit untuk menemukan titik keluar. Lebih lanjut, paren try tampaknya mengacaukan banyak hal dalam beberapa contoh.

Melihat banyak kode stdlib yang diubah seperti ini sangat berguna, jadi saya telah mengambil contoh yang sama tetapi menulis ulang sesuai proposal alternatif, yang lebih ketat:

• try sebagai kata kunci
• hanya satu try per baris
• try harus di awal baris

Semoga ini bisa membantu kita membandingkan. Secara pribadi, saya menemukan bahwa contoh-contoh ini terlihat jauh lebih ringkas daripada aslinya, tetapi tanpa mengaburkan aliran kontrol. try tetap sangat terlihat di mana pun ia digunakan.

teks/templat

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        lessOrEqual, err := le(arg1, arg2)
        if err != nil {
                return false, err
        }
        return !lessOrEqual, nil
}

menjadi:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

teks/templat

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
...
        switch v.Kind() {
        case reflect.Map:
                index, err := prepareArg(index, v.Type().Key())
                if err != nil {
                        return reflect.Value{}, err
                }
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

menjadi

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                try index := prepareArg(index, v.Type().Key())
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

regexp/sintaks:

regexp/syntax/parse.go

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        if c, t, err = nextRune(t); err != nil {
                return nil, err
        }
        p.literal(c)
        ...
}

menjadi

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        try c, t = nextRune(t)
        p.literal(c)
        ...
}

bersih/http

net/http/request.go:readRequest

        mimeHeader, err := tp.ReadMIMEHeader()
        if err != nil {
                return nil, err
        }
        req.Header = Header(mimeHeader)

menjadi:

        try mimeHeader := tp.ReadMIMEHeader()
        req.Header = Header(mimeHeader)

database/sql

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                connector, err := driverCtx.OpenConnector(dataSourceName)
                if err != nil {
                        return nil, err
                }
                return OpenDB(connector), nil
        }

menjadi

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                try connector := driverCtx.OpenConnector(dataSourceName)
                return OpenDB(connector), nil
        }

database/sql

        si, err := ctxDriverPrepare(ctx, dc.ci, query)
        if err != nil {
                return nil, err
        }
        ds := &driverStmt{Locker: dc, si: si}

menjadi

        try si := ctxDriverPrepare(ctx, dc.ci, query)
        ds := &driverStmt{Locker: dc, si: si}

bersih/http

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                cc, err := p.t.dialclientconn(addr, singleuse)
                if err != nil {
                        return nil, err
                }
                return cc, nil
        }

menjadi

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                try cc := p.t.dialclientconn(addr, singleuse)
                return cc, nil
        }

bersih/http
Yang ini sebenarnya tidak menyelamatkan kita dari baris apa pun, tetapi saya merasa jauh lebih jelas karena if err == nil adalah konstruksi yang relatif tidak umum.

func (f *http2Framer) endWrite() error {
        ...
        n, err := f.w.Write(f.wbuf)
        if err == nil && n != len(f.wbuf) {
                err = io.ErrShortWrite
        }
        return err
}

menjadi

func (f *http2Framer) endWrite() error {
        ...
        try n := f.w.Write(f.wbuf)
        if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

bersih/http

        if f, err := fr.ReadFrame(); err != nil {
                return nil, err
        } else {
                hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
        }

menjadi

        try f := fr.ReadFrame()
        hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
}

bersih:

        if ctrlFn != nil {
                c, err := newRawConn(fd)
                if err != nil {
                        return err
                }
                if err := ctrlFn(fd.ctrlNetwork(), laddr.String(), c); err != nil {
                        return err
                }
        }

menjadi

        if ctrlFn != nil {
                try c := newRawConn(fd)
                try ctrlFn(fd.ctrlNetwork(), laddr.String(), c)
        }

@james-lawrence Sebagai balasan untuk https://github.com/golang/go/issues/32437#issuecomment -500116099 : Saya tidak ingat ide seperti , err opsional sedang dipertimbangkan secara serius, tidak. Secara pribadi saya pikir itu ide yang buruk, karena itu berarti bahwa jika suatu fungsi berubah untuk menambahkan parameter error tambahan, kode yang ada akan terus dikompilasi, tetapi akan bertindak sangat berbeda.

Menggunakan penangguhan untuk menangani kesalahan sangat masuk akal, tetapi itu mengarah pada kebutuhan untuk memberi nama kesalahan dan jenis baru dari if err != nil boilerplate.

Penangan eksternal perlu melakukan ini:

func handler(err *error) {
  if *err != nil {
    *err = handle(*err)
  }
} 

yang digunakan seperti

defer handler(&err)

Penangan eksternal hanya perlu ditulis sekali tetapi perlu ada dua versi dari banyak fungsi penanganan kesalahan: yang dimaksudkan untuk ditangguhkan dan yang digunakan secara biasa.

Penangan internal perlu melakukan ini:

defer func() {
  if err != nil {
    err = handle(err)
  }
}()

Dalam kedua kasus, kesalahan fungsi luar harus diberi nama agar dapat diakses.

Seperti yang saya sebutkan sebelumnya di utas, ini dapat diabstraksikan menjadi satu fungsi:

func catch(err *error, handle func(error) error) {
  if *err != nil && handle != nil {
    *err = handle(*err)
  }
}

Itu bertentangan dengan kekhawatiran @griesemer atas ambiguitas fungsi handler nil dan memiliki boilerplate defer dan func(err error) error sendiri, selain harus memberi nama err di fungsi luar.

Jika try berakhir sebagai kata kunci, maka masuk akal untuk memiliki kata kunci catch , yang juga akan dijelaskan di bawah ini.

Secara sintaksis, itu akan seperti handle :

catch err {
  return handleThe(err)
}

Secara semantik, itu akan menjadi gula untuk kode handler internal di atas:

defer func() {
  if err != nil {
    err = handleThe(err)
  }
}()

Karena agak ajaib, itu bisa mengambil kesalahan fungsi luar, bahkan jika itu tidak disebutkan namanya. ( err setelah catch lebih mirip nama parameter untuk blok catch ).

catch akan memiliki batasan yang sama dengan try bahwa itu harus dalam fungsi yang memiliki pengembalian kesalahan akhir, karena keduanya adalah gula yang bergantung pada itu.

Itu sama sekali tidak sekuat proposal handle asli, tetapi itu akan meniadakan persyaratan untuk menyebutkan kesalahan untuk menanganinya dan itu akan menghapus boilerplate baru yang dibahas di atas untuk penangan internal sambil membuatnya cukup mudah untuk tidak memerlukan versi fungsi yang terpisah untuk penangan eksternal.

Penanganan kesalahan yang rumit mungkin mengharuskan tidak menggunakan catch sama seperti mungkin mengharuskan tidak menggunakan try .

Karena keduanya adalah gula, tidak perlu menggunakan catch dengan try . Handler catch dijalankan setiap kali fungsi mengembalikan kesalahan non- nil , yang memungkinkan, misalnya, memasukkan beberapa pencatatan cepat:

catch err {
  log.Print(err)
  return err
}

atau hanya membungkus semua kesalahan yang dikembalikan:

catch err {
  return fmt.Errorf("foo: %w", err)
}

@ianlancetaylor

_" Saya pikir itu ide yang buruk, karena itu berarti bahwa jika suatu fungsi berubah untuk menambahkan parameter error tambahan, kode yang ada akan terus dikompilasi, tetapi akan bertindak sangat berbeda."_

Itu mungkin cara yang benar untuk melihatnya, jika Anda dapat mengontrol kode hulu dan hilir sehingga jika Anda perlu mengubah tanda tangan fungsi untuk juga mengembalikan kesalahan maka Anda dapat melakukannya.

Tetapi saya akan meminta Anda untuk mempertimbangkan apa yang terjadi ketika seseorang tidak mengontrol hulu atau hilir paket mereka sendiri? Dan juga untuk mempertimbangkan kasus penggunaan di mana kesalahan mungkin ditambahkan, dan apa yang terjadi jika kesalahan perlu ditambahkan tetapi Anda tidak dapat memaksa kode hilir untuk berubah?

Bisakah Anda memikirkan contoh di mana seseorang akan mengubah tanda tangan untuk menambahkan nilai pengembalian? Bagi saya mereka biasanya termasuk dalam kategori _"Saya tidak menyadari akan terjadi kesalahan"_ atau _"Saya merasa malas dan tidak ingin berusaha karena kesalahan itu mungkin tidak akan terjadi." _

Dalam kedua kasus itu, saya mungkin menambahkan pengembalian kesalahan karena menjadi jelas bahwa kesalahan perlu ditangani. Ketika itu terjadi, jika saya tidak dapat mengubah tanda tangan karena saya tidak ingin merusak kompatibilitas untuk pengembang lain yang menggunakan paket saya, apa yang harus dilakukan? Dugaan saya adalah bahwa sebagian besar waktu kesalahan akan terjadi dan kode yang memanggil fungsi yang tidak mengembalikan kesalahan akan bertindak sangat berbeda, _anyway._

Sebenarnya, saya jarang melakukan yang terakhir tetapi terlalu sering melakukan yang pertama. Tapi saya perhatikan paket pihak ke-3 sering mengabaikan kesalahan pengambilan di tempat yang seharusnya, dan saya tahu ini karena ketika saya menampilkan kode mereka di bendera GoLand dalam warna oranye terang setiap contoh. Saya ingin sekali dapat mengirimkan permintaan tarik untuk menambahkan penanganan kesalahan ke paket yang sering saya gunakan, tetapi jika saya melakukannya sebagian besar tidak akan menerimanya karena saya akan melanggar tanda tangan kode mereka.

Dengan tidak menawarkan cara yang kompatibel ke belakang untuk menambahkan kesalahan yang akan dikembalikan oleh fungsi, pengembang yang mendistribusikan kode dan peduli untuk tidak merusak sesuatu untuk pengguna mereka tidak akan dapat mengembangkan paket mereka untuk menyertakan penanganan kesalahan sebagaimana mestinya.

Mungkin alih-alih mempertimbangkan masalahnya karena kode itu akan bertindak berbeda alih-alih melihat masalah sebagai tantangan rekayasa mengenai bagaimana meminimalkan kerugian dari metode yang tidak secara aktif menangkap kesalahan? Itu akan memiliki nilai jangka panjang dan lebih luas.

Misalnya, pertimbangkan untuk menambahkan penangan kesalahan paket yang harus ditetapkan sebelum dapat mengabaikan kesalahan?

Sejujurnya, idiom Go untuk mengembalikan kesalahan di samping nilai pengembalian reguler adalah salah satu inovasi yang lebih baik. Tetapi seperti yang sering terjadi ketika Anda memperbaiki sesuatu, Anda sering mengekspos kelemahan lain dan saya berpendapat bahwa penanganan kesalahan Go tidak cukup berinovasi.

Kami Gophers telah tenggelam dalam mengembalikan kesalahan daripada melemparkan pengecualian sehingga pertanyaan saya adalah _"Mengapa kami tidak mengembalikan kesalahan dari setiap fungsi?"_ Kami tidak selalu melakukannya karena menulis kode tanpa penanganan kesalahan adalah lebih nyaman daripada coding dengan itu. Jadi kami menghilangkan penanganan kesalahan ketika kami pikir kami bisa menghindarinya. Namun seringkali kita salah menebak.

Jadi sungguh, jika mungkin untuk mengetahui cara membuat kode elegan dan mudah dibaca, saya berpendapat bahwa nilai pengembalian dan kesalahan benar-benar harus ditangani secara terpisah, dan bahwa fungsi _setiap_ harus memiliki kemampuan untuk mengembalikan kesalahan terlepas dari tanda tangan fungsi sebelumnya. Dan membuat kode yang ada untuk menangani kode yang sekarang menghasilkan kesalahan dengan anggun akan menjadi upaya yang bermanfaat.

Saya belum mengusulkan apa pun karena saya belum dapat membayangkan sintaks yang bisa diterapkan, tetapi jika kita ingin jujur ​​pada diri kita sendiri, bukankah semua yang ada di utas ini dan terkait dengan penanganan kesalahan Go secara umum adalah tentang fakta bahwa penanganan kesalahan dan logika program adalah teman yang aneh sehingga idealnya kesalahan akan lebih baik ditangani di luar band dalam beberapa cara?

try sebagai kata kunci tentu saja membantu keterbacaan (vs. panggilan fungsi) dan tampaknya tidak terlalu rumit. @brynbellomy @crawshaw terima kasih telah meluangkan waktu untuk menulis contoh.

Saya kira pemikiran umum saya adalah bahwa try melakukan terlalu banyak. Ini memecahkan: memanggil fungsi, menetapkan variabel, memeriksa kesalahan, dan mengembalikan kesalahan jika ada. Saya mengusulkan kita sebagai gantinya memotong ruang lingkup dan menyelesaikan hanya untuk pengembalian bersyarat: "kembalikan jika argumen terakhir tidak nihil".

Ini mungkin bukan ide baru... Tapi setelah membaca sepintas proposal di wiki umpan balik kesalahan , saya tidak menemukannya (bukan berarti tidak ada)

Proposal mini tentang pengembalian bersyarat

kutipan:

err, thing := newThing(name)
refuse nil, err

Saya menambahkannya ke wiki juga di bawah "ide alternatif"

Tidak melakukan apa-apa juga sepertinya merupakan pilihan yang sangat masuk akal.

@alexhornbake yang memberi saya ide yang sedikit berbeda yang akan lebih berguna

assert(nil, err)
assert(len(a), len(b))
assert(true, condition)
assert(expected, given)

cara ini tidak hanya berlaku untuk pemeriksaan kesalahan, tetapi untuk banyak jenis kesalahan logika.

Yang diberikan akan dibungkus dengan kesalahan dan dikembalikan.

@alexhornbake

Sama seperti try sebenarnya tidak mencoba, refuse sebenarnya tidak "menolak". Maksud umum di sini adalah bahwa kita sedang menyetel "relai pelindung" ( relay singkat, akurat, dan aliteratif ke return ) yang "berjalan" ketika salah satu nilai berkabel memenuhi suatu kondisi (yaitu kesalahan non-nol). Ini semacam pemutus sirkuit dan, saya percaya, dapat menambah nilai jika desainnya terbatas pada kasing yang tidak menarik untuk sekadar mengurangi beberapa pelat ketel yang menggantung paling rendah. Apa pun yang rumit dari jarak jauh harus bergantung pada kode Go biasa.

Saya juga memuji cranshaw untuk karyanya melihat melalui perpustakaan standar, tapi saya sampai pada kesimpulan yang sangat berbeda... Saya pikir itu membuat hampir semua potongan kode lebih sulit untuk dibaca dan lebih rentan terhadap kesalahpahaman.

        req.Header = Header(try(tp.ReadMIMEHeader())

Saya akan sangat sering melewatkan bahwa ini bisa error. Pembacaan cepat membuat saya "ok, atur header ke Header of ReadMimeHeader of the thing".

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                return OpenDB(try(driverCtx.OpenConnector(dataSourceName))), nil
        }

Yang ini, mata saya hanya terbelalak mencoba mengurai baris OpenDB itu. Ada begitu banyak kepadatan di sana... Ini menunjukkan masalah utama yang dimiliki semua panggilan fungsi bersarang, di mana Anda harus membaca dari dalam ke luar, dan Anda harus menguraikannya di kepala Anda untuk mencari tahu di mana bagian terdalamnya. .

Perhatikan juga bahwa ini dapat kembali dari dua tempat berbeda di baris yang sama .. .Anda akan melakukan debugging, dan itu akan mengatakan ada kesalahan yang dikembalikan dari baris ini, dan hal pertama yang akan dilakukan semua orang adalah mencoba cari tahu mengapa OpenDB gagal dengan kesalahan aneh ini, padahal sebenarnya OpenConnector gagal (atau sebaliknya).

        ds := &driverStmt{
                Locker: dc,
                si: try(ctxDriverPrepare(ctx, dc.ci, query)),
        }   

Ini adalah tempat di mana kode bisa gagal di mana sebelumnya tidak mungkin. Tanpa try , konstruksi literal struct tidak dapat gagal . Mata saya akan melihat sekilas seperti "ok, membangun driverStmt ... pindah.." dan itu akan sangat mudah untuk dilewatkan, ini dapat menyebabkan fungsi Anda keluar dari kesalahan. Satu-satunya cara yang mungkin terjadi sebelumnya adalah jika ctxDriverPrepare panik... dan kita semua tahu bahwa 1.) pada dasarnya tidak akan pernah terjadi dan 2.) jika ya, berarti ada sesuatu yang salah secara drastis.

Mencoba kata kunci dan pernyataan memperbaiki banyak masalah saya dengannya. Saya tahu itu tidak kompatibel, tetapi saya tidak berpikir menggunakan versi yang lebih buruk itu adalah solusi untuk masalah kompatibilitas mundur.

@daved Saya tidak yakin saya mengikuti. Apakah Anda tidak menyukai namanya, atau tidak menyukai idenya?

Bagaimanapun, saya memposting ini di sini sebagai alternatif ... Jika ada minat yang sah, saya dapat membuka masalah baru untuk diskusi, tidak ingin mencemari utas ini (mungkin terlambat?) Jempol ke atas/bawah pada ide asli akan memberi kami rasa ... Tentu saja terbuka untuk nama alternatif. Bagian penting adalah "pengembalian bersyarat tanpa mencoba menangani tugas".

Meskipun saya menyukai proposal tangkapan oleh @jimmyfrasche , saya ingin mengusulkan alternatif:
go handler fmt.HandleErrorf("copy %s %s", src, dst)
akan setara dengan:
go defer func(){ if(err != nil){ fmt.HandleErrorf(&err,"copy %s %s", src, dst) } }()
di mana err adalah nilai pengembalian bernama terakhir, dengan kesalahan tipe. Namun, penangan juga dapat digunakan ketika nilai yang dikembalikan tidak disebutkan. Kasus yang lebih umum akan diizinkan juga:
go handler func(err *error){ *err = fmt.Errorf("foo: %w", *err) }() `
Masalah utama yang saya miliki dengan menggunakan nilai pengembalian bernama (yang tidak diselesaikan oleh tangkapan) adalah bahwa err berlebihan. Saat menunda panggilan ke penangan seperti fmt.HandleErrorf , tidak ada argumen pertama yang masuk akal kecuali penunjuk ke nilai pengembalian kesalahan, mengapa memberi pengguna opsi untuk membuat kesalahan?

Dibandingkan dengan catch, perbedaan utamanya adalah handler membuat sedikit lebih mudah untuk memanggil handler yang telah ditentukan dengan mengorbankan membuat lebih verbose untuk mendefinisikannya di tempat. Saya tidak yakin ini ideal, tetapi saya pikir ini lebih sesuai dengan proposal awal.

@yiyus catch , seperti yang saya definisikan, itu tidak memerlukan err untuk dinamai pada fungsi yang berisi catch .

Dalam catch err { , err adalah nama kesalahan dalam blok catch . Ini seperti nama parameter fungsi.

Dengan itu, tidak perlu sesuatu seperti fmt.HandleErrorf karena Anda cukup menggunakan fmt.Errorf biasa :

func f() error {
  catch err {
    return fmt.Errorf("foo: %w", err)
  }
  return errors.New("bar")
}

yang mengembalikan kesalahan yang dicetak sebagai foo: bar .

Saya tidak suka pendekatan ini, karena:

• Panggilan fungsi try() menginterupsi eksekusi kode dalam fungsi induk.
• tidak ada kata kunci return , tetapi kodenya benar-benar kembali.

Banyak cara untuk melakukan penangan sedang diusulkan, tetapi saya pikir mereka sering melewatkan dua persyaratan utama:

1. Itu harus berbeda secara signifikan dan lebih baik dari if x, err := thingie(); err != nil { handle(err) } . Saya pikir saran di sepanjang baris try x := thingie else err { handle(err) } tidak memenuhi standar itu. Mengapa tidak mengatakan if saja?

2. Itu harus ortogonal dengan fungsi defer yang ada. Artinya, itu harus cukup berbeda sehingga jelas bahwa mekanisme penanganan yang diusulkan diperlukan dengan sendirinya tanpa membuat kasus sudut yang aneh saat menangani dan menunda berinteraksi.

Harap ingat desiderata ini saat kita membahas mekanisme alternatif untuk try /handle.

@carlmjohnson Saya suka ide catch @jimmyfrasche mengenai poin 2 Anda - itu hanya gula sintaks untuk defer yang menghemat 2 baris dan memungkinkan Anda menghindari keharusan memberi nama nilai pengembalian kesalahan (yang dalam gilirannya juga akan mengharuskan Anda untuk menyebutkan semua yang lain jika Anda belum melakukannya). Itu tidak menimbulkan masalah ortogonalitas dengan defer , karena itu adalah defer .

menggemakan apa yang @ubombi katakan:

try() panggilan fungsi menginterupsi eksekusi kode dalam fungsi induk.; tidak ada kata kunci kembali, tetapi kode benar-benar kembali.

Di Ruby, procs dan lambda adalah contoh dari apa yang dilakukan try ...Proc adalah blok kode yang pernyataan pengembaliannya dikembalikan bukan dari blok itu sendiri, tetapi dari pemanggil.

Inilah tepatnya yang dilakukan try ...ini hanya proc Ruby yang telah ditentukan sebelumnya.

Saya pikir jika kita akan pergi ke rute itu, mungkin kita benar-benar dapat membiarkan pengguna mendefinisikan fungsi try mereka sendiri dengan memperkenalkan proc functions

Saya masih lebih suka if err != nil , karena lebih mudah dibaca tetapi saya pikir try akan lebih bermanfaat jika pengguna mendefinisikan proc mereka sendiri:

proc try(err *error, msg string) {
  if *err != nil {
    *err = fmt.Errorf("%v: %w", msg, *err)
    return
  }
}

Dan kemudian Anda dapat menyebutnya:

func someFunc() (string, error) {
  err := doSomething()
  try(&err, "someFunc failed")
}

Manfaatnya di sini, adalah Anda dapat mendefinisikan penanganan kesalahan dalam istilah Anda sendiri. Dan Anda juga dapat membuat proc terbuka, pribadi, atau internal.

Ini juga lebih baik daripada klausa handle {} dalam proposal Go2 asli karena Anda dapat mendefinisikan ini hanya sekali untuk seluruh basis kode dan tidak di setiap fungsi.

Satu pertimbangan untuk keterbacaan, adalah bahwa func() dan proc() mungkin dipanggil secara berbeda seperti func() dan proc!() sehingga programmer tahu bahwa panggilan proc mungkin benar-benar kembali dari fungsi panggilan.

@marwan-at-work, bukankah try(err, "someFunc failed") menjadi try(&err, "someFunc failed") dalam contoh Anda?

@dpinela terima kasih atas koreksinya, perbarui kodenya :)

Praktik umum yang kami coba timpa di sini adalah apa yang disarankan oleh tumpukan standar di banyak bahasa dalam pengecualian, (dan karenanya kata "coba" dipilih ...).
Tetapi jika kita hanya dapat mengizinkan fungsi(...try() atau lainnya) yang akan melompat mundur dua tingkat dalam jejak, maka

try := handler(err error) {     //which corelates with - try := func(err error) 
   if err !=nil{
       //do what ever you want to do when there's an error... log/print etc
       return2   //2 levels
   }
} 

dan kemudian kode seperti
f := coba(os.Buka(nama file))
dapat melakukan persis seperti yang disarankan proposal, tetapi sebagai fungsinya (atau sebenarnya "fungsi penangan"), pengembang akan memiliki lebih banyak kendali atas apa yang dilakukan fungsi, bagaimana memformat kesalahan dalam kasus yang berbeda, menggunakan penangan serupa di sekitar kode untuk menangani (katakanlah) os.Open, alih-alih wrting fmt.Errorf("error membuka file %s ....") setiap saat.
Ini juga akan memaksa penanganan kesalahan seolah-olah "coba" tidak akan ditentukan - ini adalah kesalahan waktu kompilasi.

@guybrand Memiliki pengembalian dua tingkat return2 (atau "pengembalian non-lokal" seperti yang disebut konsep umum di Smalltalk) akan menjadi mekanisme tujuan umum yang bagus (juga disarankan oleh @mikeschinkel di #32473) . Tetapi tampaknya try masih diperlukan dalam saran Anda, jadi saya tidak melihat alasan untuk return2 - try hanya dapat melakukan return . Akan lebih menarik jika seseorang juga dapat menulis try secara lokal, tetapi itu tidak mungkin untuk tanda tangan yang sewenang-wenang.

@griesemer

_"jadi saya tidak melihat alasan untuk return2 - try hanya dapat melakukan return ."_

Salah satu alasannya — seperti yang saya tunjukkan di #32473 _(terima kasih atas referensinya)_ — adalah untuk mengizinkan beberapa level break dan continue , selain return .

Sekali lagi terima kasih kepada semua orang untuk semua komentar baru; itu adalah investasi waktu yang signifikan untuk mengikuti diskusi dan menulis umpan balik yang luas. Dan bahkan lebih baik, terlepas dari argumen yang kadang-kadang penuh gairah, sejauh ini ini telah menjadi utas yang agak sipil. Terima kasih!

Berikut ringkasan singkat lainnya, kali ini sedikit lebih ringkas; permintaan maaf kepada mereka yang tidak saya sebutkan, lupakan, atau salah mengartikan. Pada titik ini saya pikir beberapa tema yang lebih besar sedang muncul:

1) Secara umum, menggunakan built-in untuk fungsi try dirasakan sebagai pilihan yang buruk: Mengingat hal itu mempengaruhi aliran kontrol, itu harus _setidaknya_ kata kunci ( @carloslenz "lebih suka membuat pernyataan tanpa kurung"); try sebagai ekspresi tampaknya bukan ide yang baik, itu merusak keterbacaan ( @ChrisHines , @jimmyfrasche), mereka "dikembalikan tanpa return ". @brynbellomy melakukan analisis aktual dari try yang digunakan sebagai pengidentifikasi; tampaknya hanya ada sedikit persentase, jadi mungkin saja menggunakan rute kata kunci tanpa memengaruhi terlalu banyak kode.

2) @crawshaw meluangkan waktu untuk menganalisis beberapa ratus kasus penggunaan dari perpustakaan std dan sampai pada kesimpulan bahwa try seperti yang diusulkan hampir selalu meningkatkan keterbacaan. @jimmyfrasche sampai pada kesimpulan yang berlawanan .

3) Tema lain adalah bahwa menggunakan defer untuk dekorasi kesalahan tidak ideal. @josharian menunjukkan defer 's selalu dijalankan setelah fungsi kembali, tetapi jika mereka ada di sini untuk dekorasi kesalahan, kami hanya peduli dengan tubuh mereka jika ada kesalahan, yang bisa menjadi sumber kebingungan.

4) Banyak menulis saran untuk perbaikan proposal. @zeebo , @patrick-nyt mendukung gofmt memformat pernyataan if sederhana dalam satu baris (dan senang dengan status quo). @jargv menyarankan bahwa try() (tanpa argumen) dapat mengembalikan pointer ke kesalahan "tertunda" saat ini, yang akan menghilangkan kebutuhan untuk memberi nama hasil kesalahan agar seseorang memiliki akses ke dalam defer ; @masterada menyarankan menggunakan errorfunc() sebagai gantinya. @velovix menghidupkan kembali gagasan 2-argumen try di mana argumen ke-2 akan menjadi penangan kesalahan.

@klaidliadon , @networkimprov mendukung "operator penugasan" khusus seperti di f, # := os.Open() alih-alih try . @networkimprov mengajukan proposal alternatif yang lebih komprehensif yang menyelidiki pendekatan semacam itu (lihat masalah #32500). @mikeschinkel juga mengajukan proposal alternatif yang menyarankan untuk memperkenalkan dua fitur bahasa tujuan umum baru yang dapat digunakan untuk penanganan kesalahan juga, daripada try khusus kesalahan (lihat masalah #32473). @josharian menghidupkan kembali kemungkinan yang kita diskusikan di GopherCon tahun lalu di mana try tidak kembali pada kesalahan melainkan melompat (dengan goto ) ke label bernama error (sebagai alternatif , try mungkin menggunakan nama label target).

5) Pada subjek try sebagai kata kunci, dua baris pemikiran telah muncul. @brynbellomy menyarankan versi yang mungkin dapat menentukan penangan:

a, b := try f()
a, b := try f() else err { /* handle error */ }

@thepudds melangkah lebih jauh dan menyarankan try di awal baris, memberikan try visibilitas yang sama dengan return :

try a, b := f()

Keduanya dapat bekerja dengan defer .

@griesemer

Terima kasih atas referensi ke @mikeschinkel #32473, ini memang memiliki banyak kesamaan.

tentang

Tetapi tampaknya percobaan masih diperlukan dalam saran Anda
Meskipun saran saya dapat diimplementasikan dengan penangan "apa saja" dan bukan "build in/keyword/expression" yang dicadangkan, saya tidak berpikir "coba ()" adalah ide yang buruk (dan karena itu tidak memilihnya), saya mencoba untuk "memperluasnya" - jadi itu akan menunjukkan lebih banyak sisi positif, banyak yang berharap "sekali pergi 2.0 diperkenalkan"

Saya pikir itu mungkin juga menjadi sumber "getaran campuran" yang Anda laporkan pada ringkasan terakhir Anda - ini bukan "coba () tidak meningkatkan penanganan kesalahan" - tentu saja, "menunggu Go 3.0 untuk menyelesaikan beberapa kesalahan besar lainnya menangani rasa sakit" orang-orang yang disebutkan di atas, sepertinya terlalu lama :)

Saya melakukan survei tentang "rasa sakit penanganan kesalahan" (dan terdengar beberapa rasa sakit hanyalah "Saya tidak menggunakan praktik yang baik", sedangkan beberapa saya bahkan tidak membayangkan orang (kebanyakan berasal dari bahasa lain) ingin melakukannya - dari keren ke WTF).

Semoga saya dapat segera membagikan beberapa hasil yang menarik.

terakhir -Terima kasih atas kerja keras dan kesabarannya!

Melihat hanya pada panjang sintaks yang diusulkan saat ini versus apa yang tersedia sekarang, kasus di mana kesalahan hanya perlu dikembalikan tanpa menangani atau menghiasnya adalah kasus di mana sebagian besar kenyamanan diperoleh. Contoh dengan sintaks favorit saya sejauh ini:

try a, b := f() else err { return fmt.Errorf("Decorated: %s", err); }
if a,b, err :=f;  err != nil { return fmt.Errorf("Decorated: %s", err); }
try a, b := f()
if a,b, err :=f;  err != nil { return err; }

Jadi, berbeda dari apa yang saya pikirkan sebelumnya, mungkin cukup mengubah go fmt, setidaknya untuk kasus kesalahan yang dihias/ditangani. Sementara untuk kasus kesalahan yang baru saja diteruskan, sesuatu seperti try mungkin masih diinginkan sebagai gula sintaksis untuk kasus penggunaan yang sangat umum ini.

Mengenai try else , saya pikir kesalahan bersyarat berfungsi seperti fmt.HandleErrorf (edit: Saya berasumsi itu mengembalikan nil ketika inputnya nihil) di komentar awal berfungsi dengan baik jadi menambahkan else tidak perlu.

a, b, err := doSomething()
try fmt.HandleErrorf(&err, "Decorated "...)

Seperti banyak orang lain di sini, saya lebih suka try menjadi pernyataan daripada ekspresi, terutama karena ekspresi yang mengubah aliran kontrol benar-benar asing bagi Go. Juga karena ini bukan ekspresi, itu harus di awal baris.

Saya juga setuju dengan @daved bahwa nama itu tidak pantas. Lagi pula, apa yang ingin kita capai di sini adalah tugas yang dijaga, jadi mengapa tidak menggunakan guard seperti di Swift dan menjadikan klausa else opsional? Sesuatu seperti

GuardStmt = "guard" ( Assignment | ShortVarDecl | Expression ) [  "else" Identifier Block ] .

di mana Identifier adalah nama variabel kesalahan yang terikat dalam Block berikut. Tanpa klausa else , cukup kembali dari fungsi saat ini (dan gunakan penangan penangguhan untuk menghias kesalahan jika perlu).

Awalnya saya tidak menyukai klausa else karena itu hanya gula sintaksis di sekitar tugas biasa diikuti oleh if err != nil , tetapi setelah melihat beberapa contoh, itu masuk akal: menggunakan guard membuat maksud lebih jelas.

EDIT: beberapa menyarankan untuk menggunakan hal-hal seperti catch entah bagaimana menentukan penangan kesalahan yang berbeda. Saya menemukan else sama-sama layak secara semantik dan itu sudah dalam bahasa.

Sementara saya menyukai pernyataan try-else, bagaimana dengan sintaks ini?

a, b, (err) := func() else { return err }

Ekspresi try - else adalah operator ternary.

a, b := try f() else err { ... }
fmt.Println(try g() else err { ... })`

Pernyataan try - else adalah pernyataan if .

try a, b := f() else err { ... }
// (modulo scope of err) same as
a, b, err := f()
if err != nil { ... }

try bawaan dengan handler opsional dapat dicapai dengan fungsi helper (di bawah) atau tidak menggunakan try (tidak digambarkan, kita semua tahu seperti apa tampilannya).

a, b := try(f(), decorate)
// same as
a, b := try(g())
// where g is
func g() (whatever, error) {
  x, err := f()
  if err != nil {
    try(decorate(err))
  }
  return x, nil
}

Ketiganya mengurangi boilerplate dan membantu mengatasi ruang lingkup kesalahan.

Ini memberikan penghematan paling banyak untuk try tetapi itu memiliki masalah yang disebutkan dalam dokumen desain.

Untuk pernyataan try - else , ini memberikan keuntungan dibandingkan menggunakan if daripada try . Tetapi keuntungannya sangat kecil sehingga saya sulit melihatnya membenarkan dirinya sendiri, meskipun saya menyukainya.

Ketiganya berasumsi bahwa adalah umum untuk memerlukan penanganan kesalahan khusus untuk kesalahan individu.

Menangani semua kesalahan secara merata dapat dilakukan di defer . Jika penanganan kesalahan yang sama dilakukan di setiap blok else yang agak berulang:

func printSum(a, b string) error {
  try x := strconv.Atoi(a) else err {
    return fmt.Errorf("printSum: %w", err)
  }
  try y := strconv.Atoi(b) else err {
    return fmt.Errorf("printSum: %w", err)
  }
  fmt.Println("result:", x + y)
  return nil
}

Saya tentu tahu bahwa ada kalanya kesalahan tertentu memerlukan penanganan khusus. Itulah contoh-contoh yang membekas dalam ingatan saya. Tetapi, jika itu hanya terjadi, katakanlah, 1 dari 100 kali, bukankah lebih baik menjaga try sederhana dan tidak menggunakan try dalam situasi tersebut? Di sisi lain, jika lebih seperti 1 dari 10 kali, menambahkan else /handler tampaknya lebih masuk akal.

Akan menarik untuk melihat distribusi aktual tentang seberapa sering try tanpa else /handler vs try dengan else /handler akan berguna, meskipun itu bukan data yang mudah untuk dikumpulkan.

Saya ingin memperluas komentar terbaru @jimmyfrasche .

Tujuan dari proposal ini adalah untuk mengurangi boilerplate

    a, b, err := f()
    if err != nil {
        return nil, err
    }

Kode ini mudah dibaca. Perluasan bahasa hanya layak dilakukan jika kita dapat mencapai pengurangan boilerplate yang cukup besar. Ketika saya melihat sesuatu seperti

    try a, b := f() else err { return nil, err }

Mau tak mau saya merasa bahwa kita tidak menabung sebanyak itu. Kami menyimpan tiga baris, yang bagus, tetapi menurut hitungan saya, kami mengurangi 56 menjadi 46 karakter. Itu tidak banyak. Dibandingkan dengan

    a, b := try(f())

yang memotong 56 menjadi 18 karakter, pengurangan yang jauh lebih signifikan. Dan sementara pernyataan try membuat potensi perubahan aliran kontrol lebih jelas, secara keseluruhan saya tidak menemukan pernyataan itu lebih mudah dibaca. Meskipun di sisi positifnya, pernyataan try memudahkan untuk membuat anotasi kesalahan.

Bagaimanapun, maksud saya adalah: jika kita akan mengubah sesuatu, itu akan mengurangi boilerplate secara signifikan atau harus secara signifikan lebih mudah dibaca. Yang terakhir ini cukup sulit, jadi perubahan apa pun harus benar-benar berhasil pada yang pertama. Jika kita hanya mendapatkan sedikit pengurangan boilerplate, maka menurut saya itu tidak layak dilakukan.

Seperti yang lain, saya ingin berterima kasih kepada @crawshaw untuk contohnya.

Saat membaca contoh-contoh itu, saya mendorong orang untuk mencoba mengadopsi pola pikir di mana Anda tidak khawatir tentang aliran kontrol karena fungsi try . Saya percaya, mungkin salah, bahwa aliran kontrol itu akan segera menjadi kebiasaan bagi orang-orang yang tahu bahasa itu. Dalam kasus normal, saya percaya bahwa orang akan berhenti mengkhawatirkan apa yang terjadi dalam kasus kesalahan. Coba baca contoh-contoh itu sambil melapisi try sama seperti Anda sudah melapisi if err != nil { return err } .

Setelah membaca semuanya di sini, dan setelah refleksi lebih lanjut, saya tidak yakin saya melihat try bahkan sebagai pernyataan sesuatu yang layak ditambahkan.

1. alasan untuk itu tampaknya mengurangi kesalahan penanganan kode pelat boiler. IMHO itu "mengungkapkan" kode tetapi tidak benar-benar menghilangkan kerumitannya; itu hanya mengaburkannya . Ini sepertinya bukan alasan yang cukup kuat. "pergi" sintaks ditangkap dengan indah memulai utas bersamaan. Saya tidak mendapatkan perasaan "aha!" semacam itu di sini. Rasanya tidak benar. Rasio biaya/manfaat tidak cukup besar.

2. namanya tidak mencerminkan fungsinya. Dalam bentuknya yang paling sederhana, yang dilakukannya adalah ini: "jika suatu fungsi mengembalikan kesalahan, kembali dari pemanggil dengan kesalahan" tetapi itu terlalu panjang :-) Setidaknya diperlukan nama yang berbeda.

3. dengan kesalahan pengembalian implisit try, rasanya seperti Go dengan enggan mendukung penanganan pengecualian. Yaitu jika A memanggil dalam try guard dan B memanggil C dalam try guard, dan C memanggil D dalam try guard, jika D mengembalikan kesalahan pada dasarnya Anda telah menyebabkan goto non-lokal. Rasanya terlalu "ajaib".

4. namun saya percaya cara yang lebih baik mungkin dilakukan. Memilih coba sekarang akan menutup opsi itu.

@ianlancetaylor
Jika saya memahami proposal "coba yang lain" dengan benar, tampaknya blok else adalah opsional, dan dicadangkan untuk penanganan yang disediakan pengguna. Dalam contoh Anda try a, b := f() else err { return nil, err } else sebenarnya berlebihan, dan seluruh ekspresi dapat ditulis hanya sebagai try a, b := f()

Saya setuju dengan @ianlancetaylor ,
Keterbacaan dan boilerplate adalah dua perhatian utama dan mungkin dorongan untuk
penanganan kesalahan go 2.0 (meskipun saya dapat menambahkan beberapa masalah penting lainnya)

Juga, bahwa arus

a, b, err := f()
if err != nil {
    return nil, err
}

Sangat mudah dibaca.
Dan karena saya percaya

if a, b, err := f(); err != nil {
    return nil, err
}

Hampir dapat dibaca, namun memiliki "masalah" cakupannya, mungkin a

ifErr a, b, err := f() {
    return nil, err
}

Itu hanya akan ; err != nil bagian, dan tidak akan membuat ruang lingkup, atau

demikian pula

coba a, b, err := f() {
kembali nihil, err
}

Menyimpan dua baris tambahan, tetapi masih dapat dibaca.

Pada Selasa, 11 Jun 2019, 20:19 Dmitriy Matrenichev, [email protected]
menulis:

@ianlancetaylor https://github.com/ianlancetaylor
Jika saya memahami proposal "coba yang lain" dengan benar, sepertinya itu blok lain
adalah opsional, dan disediakan untuk penanganan yang disediakan pengguna. Dalam contoh Anda
coba a, b := f() else err { return nil, err } klausa else sebenarnya
berlebihan, dan seluruh ekspresi dapat ditulis secara sederhana sebagai try a, b :=
F()

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/golang/go/issues/32437?email_source=notifications&email_token=ABNEY4XPURMASWKZKOBPBVDPZ7NALA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXH4ZLOORPVWWZ2JKTDN5WWW2
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ABNEY4SAFK4M5NLABF3NZO3PZ7NALANCNFSM4HTGCZ7Q
.

@ianlancetaylor

Bagaimanapun, maksud saya adalah: jika kita akan mengubah sesuatu, itu akan mengurangi boilerplate secara signifikan atau harus secara signifikan lebih mudah dibaca. Yang terakhir ini cukup sulit, jadi perubahan apa pun harus benar-benar berhasil pada yang pertama. Jika kita hanya mendapatkan sedikit pengurangan boilerplate, maka menurut saya itu tidak layak dilakukan.

Setuju, dan mengingat bahwa else hanya akan menjadi gula sintaksis (dengan sintaks yang aneh!), kemungkinan besar jarang digunakan, saya tidak terlalu peduli tentang itu. Saya masih lebih suka try sebagai pernyataan.

@ianlancetaylor Menggemakan @DmitriyMV , blok else akan menjadi opsional. Izinkan saya memberikan contoh yang menggambarkan keduanya (dan tampaknya tidak terlalu jauh dari sasaran dalam hal proporsi relatif dari blok try yang ditangani vs. yang tidak ditangani dalam kode nyata):

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    headRef, err := r.Head()
    if err != nil {
        return err
    }

    parentObjOne, err := headRef.Peel(git.ObjectCommit)
    if err != nil {
        return err
    }

    parentObjTwo, err := remoteBranch.Reference.Peel(git.ObjectCommit)
    if err != nil {
        return err
    }

    parentCommitOne, err := parentObjOne.AsCommit()
    if err != nil {
        return err
    }

    parentCommitTwo, err := parentObjTwo.AsCommit()
    if err != nil {
        return err
    }

    treeOid, err := index.WriteTree()
    if err != nil {
        return err
    }

    tree, err := r.LookupTree(treeOid)
    if err != nil {
        return err
    }

    remoteBranchName, err := remoteBranch.Name()
    if err != nil {
        return err
    }

    userName, userEmail, err := r.UserIdentityFromConfig()
    if err != nil {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    _, err = r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    if err != nil {
        return err
    }
    return nil
}

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    try headRef := r.Head()
    try parentObjOne := headRef.Peel(git.ObjectCommit)
    try parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    try parentCommitOne := parentObjOne.AsCommit()
    try parentCommitTwo := parentObjTwo.AsCommit()
    try treeOid := index.WriteTree()
    try tree := r.LookupTree(treeOid)
    try remoteBranchName := remoteBranch.Name()
    try userName, userEmail := r.UserIdentityFromConfig() else err {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    try r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    return nil
}

Meskipun pola try / else tidak menyimpan banyak karakter di atas gabungan if , pola tersebut:

• satukan sintaks penanganan kesalahan dengan try yang tidak ditangani
• memperjelas sekilas bahwa blok bersyarat sedang menangani kondisi kesalahan
• beri kami kesempatan untuk mengurangi keanehan pelingkupan yang diderita oleh compound if s

try yang tidak ditangani kemungkinan akan menjadi yang paling umum.

@ianlancetaylor

Coba baca contoh-contoh itu sambil berkaca-kaca coba seperti Anda sudah berkaca-kaca if err != nil { return err }.

Saya tidak berpikir itu mungkin/sama. Tidak ada percobaan yang ada di garis yang ramai, atau apa yang sebenarnya dibungkus, atau ada beberapa contoh dalam satu baris... Ini tidak sama dengan dengan mudah/cepat menandai titik kembali dan tidak mengkhawatirkan secara spesifik di dalamnya.

@ianlancetaylor

Ketika saya melihat tanda berhenti, saya mengenalinya dengan bentuk dan warna lebih daripada membaca kata yang tercetak di atasnya dan merenungkan implikasinya yang lebih dalam.

Mata saya mungkin berkaca-kaca di atas if err != nil { return err } tetapi pada saat yang sama masih mencatat—dengan jelas dan seketika.

Apa yang saya suka tentang varian try -statement adalah bahwa ia mengurangi boilerplate tetapi dengan cara yang mudah untuk diglasir tetapi sulit untuk dilewatkan.

Ini mungkin berarti garis tambahan di sana-sini tetapi itu masih lebih sedikit daripada status quo.

@brynbellomy

1. Bagaimana Anda menawarkan untuk menangani fungsi yang mengembalikan banyak nilai, seperti:
   func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) (hash , error) {
2. Bagaimana Anda melacak baris yang benar yang mengembalikan kesalahan?
3. membuang masalah ruang lingkup (yang dapat diselesaikan dengan cara lain), saya tidak yakin

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {

    if headRef, err := r.Head(); err != nil {
        return err
    } else if parentObjOne, err := headRef.Peel(git.ObjectCommit); err != nil {
        return err
    } else parentObjTwo, err := remoteBranch.Reference.Peel(git.ObjectCommit); err != nil {
        return err
    } ...

tidak begitu berbeda dari segi keterbacaan, namun (atau fmt.Errorf("error with getting head : %s", err.Error() ) memungkinkan Anda untuk memodifikasi dan memberikan data tambahan dengan mudah.

Yang masih cerewet adalah

1. harus memeriksa ulang; err != nihil
2. mengembalikan kesalahan sebagaimana adanya jika kami tidak ingin memberikan info tambahan - yang dalam beberapa kasus bukanlah praktik yang baik, karena Anda bergantung pada fungsi yang Anda panggil untuk mencerminkan kesalahan "baik" yang akan mengisyaratkan "apa yang salah ", dalam kasus file.Open , close , Remove , Db fungsi dll banyak panggilan fungsi dapat mengembalikan kesalahan yang sama (kita dapat berdebat jika itu berarti pengembang yang menulis kesalahan melakukan pekerjaan dengan baik atau tidak... TIDAK terjadi) - dan kemudian - Anda memiliki kesalahan, mungkin mencatatnya dari fungsi yang disebut
   " createMergeCommit", tetapi tidak dapat melacaknya ke baris persis di mana itu terjadi.

Maaf jika seseorang sudah memposting sesuatu seperti ini (ada banyak ide bagus :P ) Bagaimana dengan sintaks alternatif ini:

fail := func(err error) error {
  log.Print("unexpected error", err)
  return err
}

a, b, err := f1()          // normal
c, d := f2() -> throw      // calls throw(err)
e, f := f3() -> panic      // calls panic(err)
g, h := f4() -> t.Error    // calls t.Error(err)
i, j := f5() -> fail       // calls fail(err)

yaitu, Anda memiliki -> handler di sebelah kanan pemanggilan fungsi yang dipanggil jika err != nil yang dikembalikan. Handler adalah fungsi apa pun yang menerima kesalahan sebagai argumen tunggal dan secara opsional mengembalikan kesalahan (yaitu, func(error) atau func(error) error ). Jika pawang mengembalikan kesalahan nihil, fungsi berlanjut jika tidak, kesalahan dikembalikan.

jadi a := b() -> handler setara dengan:

a, err := b()
if err != nil {
  if herr := handler(err); herr != nil {
    return herr
  }
}

Sekarang, sebagai jalan pintas Anda dapat mendukung try bawaan (atau kata kunci atau operator ?= atau apa pun) yang merupakan kependekan dari a := b() -> throw sehingga Anda dapat menulis sesuatu seperti:

func() error {
  a, b := try(f1())
  c, d := try(f2())
  e, f := try(f3())
  ...
  return nil
}() -> panic // or throw/fail/whatever

Secara pribadi saya menemukan operator ?= lebih mudah dibaca daripada mencoba kata kunci/bawaan:

func() error {
  a, b ?= f1()
  c, d ?= f2()
  e, f ?= f3()
  ...
  return nil
}() -> panic

catatan : di sini saya menggunakan throw sebagai pengganti untuk builtin yang akan mengembalikan kesalahan ke pemanggil.

Saya belum mengomentari proposal penanganan kesalahan sejauh ini karena saya umumnya mendukung, dan saya suka cara mereka menuju. Baik fungsi try yang didefinisikan dalam proposal dan pernyataan try yang diusulkan oleh @thepudds sepertinya merupakan tambahan yang masuk akal untuk bahasa tersebut. Saya yakin bahwa apa pun yang dihasilkan oleh tim Go akan menjadi hal yang baik.

Saya ingin mengemukakan apa yang saya lihat sebagai masalah kecil dengan cara coba didefinisikan dalam proposal dan bagaimana hal itu dapat memengaruhi ekstensi di masa mendatang.

Coba didefinisikan sebagai fungsi yang mengambil sejumlah variabel argumen.

func try(t1 T1, t2 T2, … tn Tn, te error) (T1, T2, … Tn)

Melewati hasil pemanggilan fungsi ke try seperti pada try(f()) bekerja secara implisit karena cara beberapa nilai kembalian bekerja di Go.

Dengan membaca proposal saya, cuplikan berikut valid dan setara secara semantik.

a, b = try(f())
//
u, v, err := f()
a, b = try(u, v, err)

Proposal juga meningkatkan kemungkinan untuk memperpanjang try dengan argumen tambahan.

Jika kami menentukan di jalan bahwa memiliki beberapa bentuk fungsi pengendali kesalahan yang disediakan secara eksplisit, atau parameter tambahan lainnya dalam hal ini, adalah ide yang bagus, sangat mungkin untuk meneruskan argumen tambahan itu ke panggilan coba.

Misalkan kita ingin menambahkan argumen handler. Itu bisa di awal atau di akhir daftar argumen.

var h handler
a, b = try(h, f())
// or
a, b = try(f(), h)

Menempatkannya di awal tidak berhasil, karena (mengingat semantik di atas) try tidak akan dapat membedakan antara argumen handler eksplisit dan fungsi yang mengembalikan handler.

func f() (handler, error) { ... }
func g() (error) { ... }
try(f())
try(h, g())

Menempatkannya di akhir mungkin akan berhasil, tetapi kemudian try akan menjadi unik dalam bahasa sebagai satu-satunya fungsi dengan parameter varargs di awal daftar argumen.

Tak satu pun dari masalah ini adalah penghenti, tetapi mereka membuat try merasa tidak konsisten dengan bahasa lainnya, jadi saya tidak yakin try akan mudah diperluas di masa mendatang karena status proposal.

@gaib

Memiliki penangan itu kuat, mungkin:
Saya Anda sudah menyatakan h,

kamu bisa

var h handler
a, b, h = f()

atau

a, b, h.err = f()

jika fungsinya seperti:

h:= handler(err error){
 log(...)
 return ....
} 

Lalu ada saran untuk

a, b, h(err) = f()

Semua dapat memanggil pawang
Dan Anda juga dapat "memilih" penangan yang mengembalikan atau hanya menangkap kesalahan (lanjutan/istirahat/kembali) seperti yang disarankan beberapa orang.

Dan dengan demikian masalah varargs hilang.

Salah satu alternatif dari saran else @brynbellomy tentang:

a, b := try f() else err { /* handle error */ }

bisa untuk mendukung fungsi dekorasi segera setelah yang lain:

decorate := func(err error) error { return fmt.Errorf("foo failed: %v", err) }

try a, b := f() else decorate
try c, d := g() else decorate

Dan mungkin juga beberapa utilitas berfungsi seperti:

decorate := fmt.DecorateErrorf("foo failed")

Fungsi dekorasi dapat memiliki tanda tangan func(error) error , dan dipanggil oleh try jika ada kesalahan, tepat sebelum try kembali dari fungsi terkait yang sedang dicoba.

Itu akan serupa dalam semangat dengan salah satu "iterasi desain" sebelumnya dari dokumen proposal:

f := try(os.Open(filename), handler)              // handler will be called in error case

Jika seseorang menginginkan sesuatu yang lebih kompleks atau blok pernyataan, mereka dapat menggunakan if (seperti yang mereka dapat sekarang).

Yang mengatakan, ada sesuatu yang bagus tentang perataan visual try yang ditunjukkan dalam contoh @brynbellomy di https://github.com/golang/go/issues/32437#issuecomment -500949780.

Semua ini masih dapat bekerja dengan defer jika pendekatan itu dipilih untuk dekorasi kesalahan seragam (atau bahkan secara teori mungkin ada bentuk alternatif untuk mendaftarkan fungsi dekorasi, tetapi itu adalah poin terpisah).

Bagaimanapun, saya tidak yakin apa yang terbaik di sini, tetapi ingin membuat opsi lain eksplisit.

Berikut contoh @brynbellomy yang ditulis ulang dengan fungsi try , menggunakan blok var untuk mempertahankan keselarasan yang bagus yang ditunjukkan oleh @thepudds di https://github.com/golang/go/issues /32437#issuecomment -500998690.

package main

import (
    "fmt"
    "time"
)

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    var (
        headRef          = try(r.Head())
        parentObjOne     = try(headRef.Peel(git.ObjectCommit))
        parentObjTwo     = try(remoteBranch.Reference.Peel(git.ObjectCommit))
        parentCommitOne  = try(parentObjOne.AsCommit())
        parentCommitTwo  = try(parentObjTwo.AsCommit())
        treeOid          = try(index.WriteTree())
        tree             = try(r.LookupTree(treeOid))
        remoteBranchName = try(remoteBranch.Name())
    )

    userName, userEmail, err := r.UserIdentityFromConfig()
    if err != nil {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    _, err = r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    return err
}

Ini sesingkat versi pernyataan try -, dan saya berpendapat sama dapat dibaca. Karena try adalah sebuah ekspresi, beberapa dari variabel perantara tersebut dapat dihilangkan, dengan mengorbankan beberapa keterbacaan, tetapi itu tampaknya lebih seperti masalah gaya daripada yang lainnya.

Itu menimbulkan pertanyaan tentang bagaimana try bekerja di blok var . Saya menganggap setiap baris dari var dihitung sebagai pernyataan terpisah, daripada seluruh blok menjadi pernyataan tunggal, sejauh urutan apa yang ditugaskan kapan.

Akan lebih baik jika proposal "coba" secara eksplisit menyebutkan konsekuensi untuk alat seperti cmd/cover yang memperkirakan statistik cakupan pengujian menggunakan penghitungan pernyataan naif. Saya khawatir bahwa aliran kontrol kesalahan yang tidak terlihat dapat mengakibatkan penghitungan yang kurang.

@thepudds

coba a, b := f() kalau tidak hias

Mungkin luka bakarnya terlalu dalam di sel-sel otakku, tapi ini terlalu memukulku sebagai

try a, b := f() ;catch(decorate)

dan lereng licin ke a

a, b := f()
catch(decorate)

Saya pikir Anda dapat melihat ke mana arahnya, dan bagi saya membandingkan

    try headRef := r.Head()
    try parentObjOne := headRef.Peel(git.ObjectCommit)
    try parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    try parentCommitOne := parentObjOne.AsCommit()
    try parentCommitTwo := parentObjTwo.AsCommit()
    try treeOid := index.WriteTree()
    try tree := r.LookupTree(treeOid)
    try remoteBranchName := remoteBranch.Name()

dengan

    try ( 
    headRef := r.Head()
    parentObjOne := headRef.Peel(git.ObjectCommit)
    parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    parentCommitOne := parentObjOne.AsCommit()
    parentCommitTwo := parentObjTwo.AsCommit()
    treeOid := index.WriteTree()
    tree := r.LookupTree(treeOid)
    remoteBranchName := remoteBranch.Name()
    )

(atau bahkan tangkapan di akhir)
Yang kedua lebih mudah dibaca, tetapi menekankan fakta bahwa fungsi di bawah mengembalikan 2 vars, dan kami secara ajaib membuang satu, mengumpulkannya menjadi "magic return err" .

    try(err) ( 
    headRef := r.Head()
    parentObjOne := headRef.Peel(git.ObjectCommit)
    parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    parentCommitOne := parentObjOne.AsCommit()
    parentCommitTwo := parentObjTwo.AsCommit()
    treeOid := index.WriteTree()
    tree := r.LookupTree(treeOid)
    remoteBranchName := remoteBranch.Name()
    ); err!=nil {
      //handle the err
    }

setidaknya secara eksplisit mengatur variabel untuk dikembalikan, dan biarkan saya menanganinya di dalam fungsi, kapan pun saya mau.

Hanya menyela komentar tertentu karena saya tidak melihat orang lain secara eksplisit menyebutkannya, khususnya tentang mengubah gofmt untuk mendukung pemformatan baris tunggal berikut, atau varian apa pun:

if f() { return nil, err }

Kumohon tidak. Jika kita ingin satu baris if maka silahkan buat satu baris if , misalnya:

if f() then return nil, err

Tapi tolong, tolong, tolong, jangan merangkul sintaksis salad menghapus jeda baris yang membuatnya lebih mudah untuk membaca kode yang menggunakan kurung kurawal.

Saya ingin menekankan beberapa hal yang mungkin telah dilupakan dalam panasnya diskusi:

1) Inti dari proposal ini adalah untuk membuat penanganan kesalahan umum memudar ke latar belakang - penanganan kesalahan tidak boleh mendominasi kode. Tapi harus tetap eksplisit. Salah satu saran alternatif yang membuat penanganan kesalahan semakin menonjol tidak ada gunanya. Seperti yang sudah dikatakan @ianlancetaylor , jika saran alternatif ini tidak mengurangi jumlah boilerplate secara signifikan, kita bisa tetap menggunakan pernyataan if . (Dan permintaan untuk mengurangi boilerplate datang dari Anda, komunitas Go.)

2) Salah satu keluhan tentang proposal saat ini adalah kebutuhan untuk menyebutkan hasil kesalahan untuk mendapatkan akses ke sana. Setiap proposal alternatif akan memiliki masalah yang sama kecuali jika alternatif tersebut memperkenalkan sintaks tambahan, yaitu, lebih banyak boilerplate (seperti ... else err { ... } dan sejenisnya) untuk secara eksplisit menamai variabel tersebut. Tetapi yang menarik: Jika kita tidak peduli dengan mendekorasi kesalahan dan tidak memberi nama parameter hasil, tetapi masih memerlukan return eksplisit karena ada semacam penangan eksplisit, pernyataan return itu harus menghitung semua nilai hasil (biasanya nol) karena pengembalian telanjang tidak diizinkan dalam kasus ini. Terutama jika suatu fungsi melakukan banyak pengembalian kesalahan tanpa mendekorasi kesalahan, pengembalian eksplisit tersebut ( return nil, err , dll.) ditambahkan ke boilerplate. Proposal saat ini, dan alternatif apa pun yang tidak memerlukan return eksplisit menghapusnya. Di sisi lain, jika seseorang memang ingin menghias kesalahan, proposal saat ini _memerlukan_ bahwa satu nama hasil kesalahan (dan dengan itu semua hasil lainnya) untuk mendapatkan akses ke nilai kesalahan. Ini memiliki efek samping yang bagus bahwa dalam penangan eksplisit seseorang dapat menggunakan pengembalian telanjang dan tidak harus mengulangi semua nilai hasil lainnya. (Saya tahu ada beberapa perasaan kuat tentang pengembalian telanjang, tetapi kenyataannya adalah bahwa ketika semua yang kita pedulikan adalah hasil kesalahan, itu adalah gangguan nyata untuk menghitung semua nilai hasil lainnya (biasanya nol) - itu tidak menambahkan apa pun ke pemahaman kode). Dengan kata lain, harus menamai hasil kesalahan agar dapat didekorasi memungkinkan pengurangan lebih lanjut dari pelat ketel.

@magical Terima kasih telah menunjukkan ini . Saya melihat hal yang sama segera setelah memposting proposal (tetapi tidak membawanya agar tidak menimbulkan kebingungan lebih lanjut). Anda benar bahwa try tidak dapat diperpanjang. Untungnya perbaikannya cukup mudah. (Kebetulan proposal internal kami sebelumnya tidak memiliki masalah ini - itu diperkenalkan ketika saya menulis ulang versi final kami untuk publikasi dan mencoba menyederhanakan try untuk mencocokkan aturan melewati parameter yang ada lebih dekat. Sepertinya bagus - tetapi ternyata, cacat, dan sebagian besar tidak berguna - manfaat untuk dapat menulis try(a, b, c, handle) .)

Versi sebelumnya dari try mendefinisikannya secara kasar sebagai berikut: try(expr, handler) mengambil satu (atau mungkin dua) ekspresi sebagai argumen, di mana ekspresi pertama mungkin multi-nilai (hanya dapat terjadi jika ekspresinya adalah panggilan fungsi). Nilai terakhir dari ekspresi tersebut (mungkin multi-nilai) harus bertipe error , dan nilai tersebut diuji terhadap nil. (dll. - sisanya dapat Anda bayangkan).

Bagaimanapun, intinya adalah bahwa try secara sintaksis hanya menerima satu, atau mungkin dua ekspresi. (Tapi agak sulit untuk menggambarkan semantik dari try .) Konsekuensinya adalah kode seperti:

a, b := try(u, v, err)

tidak akan diizinkan lagi. Tapi ada sedikit alasan untuk membuat ini bekerja di tempat pertama: Dalam kebanyakan kasus (kecuali a dan b diberi nama hasil) kode ini - jika penting untuk beberapa alasan - dapat ditulis ulang dengan mudah menjadi

a, b := u, v  // we don't care if the assignment happens in case of an error
try(err)

(atau gunakan pernyataan if sesuai kebutuhan). Tapi sekali lagi, ini sepertinya tidak penting.

pernyataan pengembalian itu harus menghitung semua nilai hasil (biasanya nol) karena pengembalian telanjang tidak diizinkan dalam kasus ini

Pengembalian telanjang tidak diizinkan, tetapi cobalah. Satu hal yang saya suka tentang try (baik sebagai fungsi atau pernyataan) adalah bahwa saya tidak perlu memikirkan cara mengatur nilai non-error saat mengembalikan kesalahan lagi, saya hanya akan menggunakan try.

@griesemer Terima kasih atas penjelasannya. Itu juga kesimpulan yang saya dapatkan.

Komentar singkat tentang try sebagai pernyataan: seperti yang saya pikir dapat dilihat pada contoh di https://github.com/golang/go/issues/32437#issuecomment -501035322, try mengubur lede. Kode menjadi serangkaian pernyataan try , yang mengaburkan apa yang sebenarnya dilakukan kode.

Kode yang ada dapat menggunakan kembali variabel kesalahan yang baru dideklarasikan setelah blok if err != nil . Menyembunyikan variabel akan merusaknya, dan menambahkan variabel pengembalian bernama ke tanda tangan fungsi tidak akan selalu memperbaikinya.

Mungkin yang terbaik adalah membiarkan deklarasi/penugasan kesalahan apa adanya, dan menemukan stmt penanganan kesalahan satu baris.

err := f() // followed by one of

on err, return err            // any type can be tested for non-zero
on err, return fmt.Errorf(...)
on err, fmt.Println(err)      // doesn't stop the function
on err, hname err             // handler invocation without parens
on err, ignore err            // optional ignore handler logs error if defined

if err, return err            // alternatively, use if

handle hname(err error, clr caller) { // type caller has results of runtime.Caller()
   if err == io.Bad { return err }
   fmt.Println(clr.name, err)
}

Subekspresi try bisa panik, artinya kesalahan tidak pernah diharapkan. Varian dari itu dapat mengabaikan kesalahan apa pun.

f(try g()) // panic on error
f(try_ g()) // ignore any error

Inti dari proposal ini adalah untuk membuat penanganan kesalahan umum memudar ke latar belakang - penanganan kesalahan tidak boleh mendominasi kode. Tapi harus tetap eksplisit.

Saya suka ide komentar yang mencantumkan try sebagai pernyataan. Ini eksplisit, masih mudah untuk dipoles (karena panjangnya tetap), tetapi tidak _so_ mudah untuk dipoles (karena selalu di tempat yang sama) sehingga dapat disembunyikan di barisan yang ramai. Itu juga dapat digabungkan dengan defer fmt.HandleErrorf(...) seperti yang disebutkan sebelumnya, namun memiliki perangkap menyalahgunakan parameter bernama untuk membungkus kesalahan (yang masih tampak seperti peretasan yang cerdas bagi saya. peretasan pintar itu buruk.)

Salah satu alasan saya tidak menyukai try sebagai ekspresi adalah karena terlalu mudah untuk disamarkan, atau tidak cukup mudah untuk disamarkan. Ambil dua contoh berikut:

Coba sebagai ekspresi

// Too hidden, it's in a crowded function with many symbols that complicate the function.

f, err := os.OpenFile(try(FileName()), os.O_APPEND|os.O_WRONLY, 0600)

// Not easy enough, the word "try" already increases horizontal complexity, and it
// being an expression only encourages more horizontal complexity.
// If this code weren't collapsed to multiple lines, it would be extremely
// hard to read and unclear as to what's executing when.

fullContents := try(io.CopyN(
    os.Stdout,
    try(net.Dial("tcp", "localhost:"+try(buf.ReadString("\n"))),
    try(strconv.Atoi(try(buf.ReadString("\n")))),
))

Coba sebagai pernyataan

// easy to see while still not being too verbose

try name := FileName()
os.OpenFile(name, os.O_APPEND|os.O_WRONLY, 0600)

// does not allow for clever one-liners, code remains much more readable.
// also, the code reads in sequence from top-to-bottom.

try port := r.ReadString("\n")
try lengthStr := r.ReadString("\n")
try length := strconv.Atoi(lengthStr)

try con := net.Dial("tcp", "localhost:"+port)
try io.CopyN(os.Stdout, con, length)

Bawa pulang

Kode ini pasti dibuat-buat, saya akui. Tapi yang saya maksud adalah, secara umum, try sebagai ekspresi tidak berfungsi dengan baik di:

1. Di tengah ekspresi ramai yang tidak perlu banyak pengecekan kesalahan
2. Pernyataan multiline yang relatif sederhana yang membutuhkan banyak pemeriksaan kesalahan

Namun saya setuju dengan @ianlancetaylor bahwa memulai setiap baris dengan try tampaknya menghalangi bagian penting dari setiap pernyataan (variabel yang didefinisikan atau fungsi yang dieksekusi). Namun saya pikir karena berada di lokasi yang sama dan lebarnya tetap, lebih mudah untuk menutupinya, sambil tetap memperhatikannya. Namun, mata setiap orang berbeda.

Saya juga berpikir mendorong one-liners yang pintar dalam kode hanyalah ide yang buruk secara umum. Saya terkejut bahwa saya bisa membuat one-liner yang begitu kuat seperti pada contoh pertama saya, ini adalah snippet yang layak mendapatkan seluruh fungsinya karena melakukan begitu banyak - tetapi cocok pada satu baris jika saya tidak menciutkannya ke beberapa demi keterbacaan. Semua dalam satu baris:

fullContents := try(io.CopyN(os.Stdout, try(net.Dial("tcp", "localhost:"+try(r.ReadString("\n"))), try(strconv.Atoi(try(r.ReadString("\n"))))))

Itu membaca port dari *bufio.Reader , memulai koneksi TCP, dan menyalin sejumlah byte yang ditentukan oleh *bufio.Reader yang sama ke stdout . Semua dengan penanganan kesalahan. Untuk bahasa dengan konvensi pengkodean yang ketat, saya rasa ini tidak boleh diizinkan. Saya kira gofmt dapat membantu dengan ini.

Untuk bahasa dengan konvensi pengkodean yang ketat, saya rasa ini tidak boleh diizinkan.

Dimungkinkan untuk menulis kode yang menjijikkan di Go. Bahkan dimungkinkan untuk memformatnya dengan sangat buruk; hanya ada norma dan alat yang kuat untuk menentangnya. Go bahkan memiliki goto .

Selama tinjauan kode, saya terkadang meminta orang untuk memecah ekspresi rumit menjadi beberapa pernyataan, dengan nama perantara yang berguna. Saya akan melakukan hal serupa untuk try s yang sangat bersarang, untuk alasan yang sama.

Artinya: Mari kita tidak berusaha terlalu keras untuk melarang kode yang buruk, dengan biaya mendistorsi bahasa. Kami memiliki mekanisme lain untuk menjaga kode tetap bersih yang lebih cocok untuk sesuatu yang pada dasarnya melibatkan penilaian manusia berdasarkan kasus per kasus.

Dimungkinkan untuk menulis kode yang menjijikkan di Go. Bahkan dimungkinkan untuk memformatnya dengan sangat buruk; hanya ada norma dan alat yang kuat untuk menentangnya. Pergi bahkan harus.

Selama tinjauan kode, saya terkadang meminta orang untuk memecah ekspresi rumit menjadi beberapa pernyataan, dengan nama perantara yang berguna. Saya akan melakukan hal serupa untuk percobaan yang sangat bersarang, untuk alasan yang sama.

Artinya: Mari kita tidak berusaha terlalu keras untuk melarang kode yang buruk, dengan biaya mendistorsi bahasa. Kami memiliki mekanisme lain untuk menjaga kode tetap bersih yang lebih cocok untuk sesuatu yang pada dasarnya melibatkan penilaian manusia berdasarkan kasus per kasus.